From iesg-secretary@ietf.org Mon Jan 3 07:12:30 2011 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6AD8A3A69FF; Mon, 3 Jan 2011 07:12:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RdTXR8fy2SbV; Mon, 3 Jan 2011 07:12:29 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 395933A6A00; Mon, 3 Jan 2011 07:12:29 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.10 Message-ID: <20110103151229.24914.73314.idtracker@localhost> Date: Mon, 03 Jan 2011 07:12:29 -0800 Cc: mext mailing list , Internet Architecture Board , mext chair , RFC Editor Subject: [MEXT] Protocol Action: 'DHCPv6 Prefix Delegation for NEMO' to Proposed Standard (draft-ietf-mext-nemo-pd-07.txt) X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jan 2011 15:12:30 -0000 The IESG has approved the following document: - 'DHCPv6 Prefix Delegation for NEMO' (draft-ietf-mext-nemo-pd-07.txt) as a Proposed Standard This document is the product of the Mobility EXTensions for IPv6 Working Group. The IESG contact persons are Jari Arkko and Ralph Droms. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-mext-nemo-pd/ Technical Summary One aspect of network mobility support is the assignment of a prefix or prefixes to a Mobile Router (MR) for use on the links in the NEMO. DHCPv6 prefix delegation can be used for this configuration task. Working Group Summary The normal WG process was followed and the document has been discussed for several years. The document as it is now, reflects WG consensus, with nothing special worth noting. Document Quality The document was thoroughly reviewed by Jean-Michel Combes, Michaela Vanderveen, and Julien Laganier. Personnel The Document Shepherd is Julien Laganier, and the responsible Area Director is Jari Arkko. From jari.arkko@piuha.net Tue Jan 11 02:51:54 2011 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E370D28C11B; Tue, 11 Jan 2011 02:51:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.54 X-Spam-Level: X-Spam-Status: No, score=-102.54 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6gp0Pd9rj5DB; Tue, 11 Jan 2011 02:51:50 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 146DE28C114; Tue, 11 Jan 2011 02:51:48 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id A40BC2CC2F; Tue, 11 Jan 2011 12:54:04 +0200 (EET) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xyEwHihhGT38; Tue, 11 Jan 2011 12:54:03 +0200 (EET) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id E93EF2CC2D; Tue, 11 Jan 2011 12:54:02 +0200 (EET) Message-ID: <4D2C36CA.3040008@piuha.net> Date: Tue, 11 Jan 2011 12:54:02 +0200 From: Jari Arkko User-Agent: Thunderbird 2.0.0.24 (X11/20101027) MIME-Version: 1.0 To: "mext@ietf.org" Content-Type: multipart/mixed; boundary="------------050005070408030106000604" Cc: dmm@ietf.org Subject: [MEXT] suggest charter item for distributed mobility work X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2011 10:51:54 -0000 This is a multi-part message in MIME format. --------------050005070408030106000604 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit All, I have been thinking about what to do about the distributed mobility work since our meeting in Beijing. My suggestion is to add a work item to the MEXT charter. Here's the proposed new item: Jari --------------050005070408030106000604 Content-Type: text/plain; name="charterjan2011withdmm.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="charterjan2011withdmm.txt" Mobility EXTensions for IPv6 (mext) ----------------------------------- Current Status: Active Chairs: Marcelo Bagnulo Julien Laganier Internet Area Directors: Ralph Droms Jari Arkko Internet Area Advisor: Jari Arkko Mailing Lists: General Discussion: mext@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/mext Archive: http://www.ietf.org/mail-archive/web/mext Description of Working Group: Mobile IPv6 specifies routing support which permits an IPv6 host to continue using its home address as it moves around the Internet, enabling continuity of sessions. Mobile IPv6 supports transparency above the IP layer, including maintenance of active transport level sessions. In addition, network mobility (NEMO) mechanisms built on top of Mobile IPv6 allow managing the mobility of an entire network, as it changes its point of attachment to the Internet. The base specifications consist of: o RFC 3775 (Mobile IPv6) o RFC 3963 (NEMO) o RFC 4877 (Mobile IPv6 Operation with IKEv2) o RFC 5555 (Dual Stack Mobile IPv6) o RFC 5648 (Multiple Care-of Addresses Registration) o RFC 5846 (Binding Revocation) o RFC-to-be (Flow Binding Policy Transport and Flow Binding Policy Format) The MEXT Working Group continues the work of the former MIP6, NEMO, and MONAMI6 Working Groups. The primary goal of MEXT will be to enhance base IPv6 mobility by continuing work on developments that are required for wide-scale deployments and specific deployment scenarios. Additionally, the working group will ensure that any issues identified by implementation and interoperability experience are addressed, and that the base specifications are maintained. The group will also produce informational documentation, such as design rationale documents or description of specific issues within the protocol. The MEXT WG will also explore experimental alternative security mechanisms. The security mechanism specified in the existing standard track RFCs (RFC3775bis, RFC4877) remains the mandatory to implement mechanism that guarantees interoperability between different implementations. The MEXT WG is chartered to deliver one or more experimental alternative mechanisms. All the alternative solutions will be published as experimental RFCs. The working group will also work on operational considerations on setting up Mobile IPv6 networks so that traffic is distributed in an optimal way, for instance by using existing protocol mechanisms to select the closest home agents for new clients. In addition, the working group will bring to completion earlier work on prefix delegation for NEMO, RADIUS support for Mobile IPv6, Mobile IPv6 operation with firewalls, and home agent reliability specifications. Work items related to base specification maintenance include: Create and maintain issue lists that are generated on the basis of implementation and interoperability experience. Address specific issues with specific updates or revisions of the base specification. Currently known specific issues include support for overlapping (private) IPv4 home addresses, negotiation of the protection required for payload traffic, and discovery of the home agent address in IPv4-only networks. Goals and Milestones: Jun 2011 - Submit I-D 'Mobile IPv6 Operation with Firewalls' to IESG for publication as Informational. Jun 2011 - Submit I-D 'Home agent reliability' to IESG for publication as a Proposed Standard. Aug 2011 - Submit I-Ds on alternative security mechanisms to the IESG for publication as Experimental. Sep 2011 - Submit I-D 'Overlapping IPv4 address support' to IESG for publication as Proposed Standard. Sep 2011 - Submit I-D 'Home agent discovery in IPv4-only networks via DHCP' to IESG for publication as Proposed Standard. Oct 2011 - Submit I-D 'Operational considerations for distributed use of Mobile IPv6' for publication as Informational Dec 2011 - Submit I-D 'Negotiation of the protection for payload traffic' to IESG for publication as Proposed Standard. Dec 2011 - Submit the I-D 'RADIUS Mobile IPv6 Support' to IESG for publication as a proposed standard. --------------050005070408030106000604 Content-Type: text/html; charset=ISO-8859-1; name="charterjan2011withdmm-from-.diff.html" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="charterjan2011withdmm-from-.diff.html" Diff: charterjan2011.txt - charterjan2011withdmm.txt
 charterjan2011.txt   charterjan2011withdmm.txt 
skipping to change at line 60 skipping to change at line 60
specific issues within the protocol. specific issues within the protocol.
The MEXT WG will also explore experimental alternative security The MEXT WG will also explore experimental alternative security
mechanisms. The security mechanism specified in the existing standard mechanisms. The security mechanism specified in the existing standard
track RFCs (RFC3775bis, RFC4877) remains the mandatory to implement track RFCs (RFC3775bis, RFC4877) remains the mandatory to implement
mechanism that guarantees interoperability between different mechanism that guarantees interoperability between different
implementations. The MEXT WG is chartered to deliver one or more implementations. The MEXT WG is chartered to deliver one or more
experimental alternative mechanisms. All the alternative solutions will experimental alternative mechanisms. All the alternative solutions will
be published as experimental RFCs. be published as experimental RFCs.
The working group will also work on operational considerations on
setting up Mobile IPv6 networks so that traffic is distributed
in an optimal way, for instance by using existing protocol mechanisms
to select the closest home agents for new clients.
In addition, the working group will bring to completion earlier work on In addition, the working group will bring to completion earlier work on
prefix delegation for NEMO, RADIUS support for Mobile IPv6, Mobile IPv6 prefix delegation for NEMO, RADIUS support for Mobile IPv6, Mobile IPv6
operation with firewalls, and home agent reliability specifications. operation with firewalls, and home agent reliability specifications.
Work items related to base specification maintenance include: Create and Work items related to base specification maintenance include: Create and
maintain issue lists that are generated on the basis of implementation maintain issue lists that are generated on the basis of implementation
and interoperability experience. Address specific issues with specific and interoperability experience. Address specific issues with specific
updates or revisions of the base specification. Currently known specific updates or revisions of the base specification. Currently known specific
issues include support for overlapping (private) IPv4 home addresses, issues include support for overlapping (private) IPv4 home addresses,
negotiation of the protection required for payload traffic, and negotiation of the protection required for payload traffic, and
discovery of the home agent address in IPv4-only networks. discovery of the home agent address in IPv4-only networks.
Goals and Milestones: Goals and Milestones:
Done - Submit I-D 'Mobile IPv6 Vendor Specific Option' to IESG for publication as a Proposed Standard Jun 2011 - Submit I-D 'Mobile IPv6 Operation with Firewalls' to IESG for publication as Informational.
Done - Submit I-D 'Mobile IPv6 Experimental Allocations' to IESG for publication as a Proposed Standard Jun 2011 - Submit I-D 'Home agent reliability' to IESG for publication as a Proposed Standard.
Done - Submit I-D 'Mobile IPv6 Dual-Stack Operation' to IESG for publication as a Proposed Standard.
Done - Submit I-D 'Motivation for Authentication I-D' to IESG for publication as Informational.
Done - Submit Multiple CoA Registration to IESG
Done - Submit I-D 'Goals for AAA HA Interface' to IESG for publication as Informational.
Done - Submit -00 draft on Route Optimization Needs for Automobile and Highway Deployments
Done - Submit -00 draft on Route Optimization Needs for Aircraft and Spacecraft Deployments
Done - Submit I-D 'Mobility Header Home Agent Switch Message' to IESG for publication as a Proposed Standard
Done - Submit final doc on Route Optimization Needs for Aircraft and Spacecraft Deployments, for Informational
Done - Submit 00 draft on Binding Revocation
Done - Submit the final doc on MIB for NEMO Basic Support to the IESG, for Proposed Standard
Done - Submit draft on Binding Revocation to IESG
Done - Submit I-D(s) related to specific updates and corrections of RFC 3775 to IESG for publication as Proposed Standard.
Done - Submit the final doc on Prefix Delegation for NEMO to the IESG, for Proposed Standard
Dec 2010 - Submit the I-D 'RADIUS Mobile IPv6 Support' to IESG for publication as a proposed standard.
Jan 2011 - Submit I-D 'Mobile IPv6 Operation with Firewalls' to IESG for publication as Informational.
Jan 2011 - Submit I-D 'Home agent reliability' to IESG for publication as a Proposed Standard.
Aug 2011 - Submit I-Ds on alternative security mechanisms to the IESG for publication as Experimental. Aug 2011 - Submit I-Ds on alternative security mechanisms to the IESG for publication as Experimental.
Sep 2011 - Submit I-D 'Overlapping IPv4 address support' to IESG for publication as Proposed Standard. Sep 2011 - Submit I-D 'Overlapping IPv4 address support' to IESG for publication as Proposed Standard.
Sep 2011 - Submit I-D 'Home agent discovery in IPv4-only networks via DHCP' to IESG for publication as Proposed Standard. Sep 2011 - Submit I-D 'Home agent discovery in IPv4-only networks via DHCP' to IESG for publication as Proposed Standard.
Oct 2011 - Submit I-D 'Operational considerations for distributed use of Mobile IPv6' for publication as Informational
Dec 2011 - Submit I-D 'Negotiation of the protection for payload traffic' to IESG for publication as Proposed Standard. Dec 2011 - Submit I-D 'Negotiation of the protection for payload traffic' to IESG for publication as Proposed Standard.
Dec 2011 - Submit the I-D 'RADIUS Mobile IPv6 Support' to IESG for publication as a proposed standard.
 End of changes. 4 change blocks. 
18 lines changed or deleted 8 lines changed or added

This html diff was produced by rfcdiff 1.32. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/
--------------050005070408030106000604-- From sgundave@cisco.com Wed Jan 19 19:11:46 2011 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E2B463A7098; Wed, 19 Jan 2011 19:11:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.601 X-Spam-Level: X-Spam-Status: No, score=-9.601 tagged_above=-999 required=5 tests=[AWL=-0.399, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PfejFldhAKWa; Wed, 19 Jan 2011 19:11:19 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 06A543A7099; Wed, 19 Jan 2011 19:11:19 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjgFANA2N02rR7Ht/2dsb2JhbACCQaEqX3OiFZp5hVAEhG89hXKDKoJz Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-4.cisco.com with ESMTP; 20 Jan 2011 03:13:59 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p0K3Dxp7021192; Thu, 20 Jan 2011 03:13:59 GMT Received: from xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 19 Jan 2011 19:13:59 -0800 Received: from 10.32.246.211 ([10.32.246.211]) by xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) with Microsoft Exchange Server HTTP-DAV ; Thu, 20 Jan 2011 03:13:59 +0000 User-Agent: Microsoft-Entourage/12.28.0.101117 Date: Wed, 19 Jan 2011 19:14:06 -0800 From: Sri Gundavelli To: Jari Arkko , "mext@ietf.org" Message-ID: Thread-Topic: [MEXT] suggest charter item for distributed mobility work Thread-Index: Acu4UBic4/afIk6erka9FoImdwJyrQ== In-Reply-To: <4D2C36CA.3040008@piuha.net> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3378309246_16548777" X-OriginalArrivalTime: 20 Jan 2011 03:13:59.0921 (UTC) FILETIME=[14FCFE10:01CBB850] Cc: dmm@ietf.org Subject: Re: [MEXT] suggest charter item for distributed mobility work X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jan 2011 03:11:46 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3378309246_16548777 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Hi Jari: Thanks for the updated charter text. This looks good to me. Just couple of comments. * The approach of closest home agent selection is one aspect of the DMM proposal. I assumed it includes other aspects such as CP/DP separation. Does the charter text gives such provision for such extensions ? * The BOF discussed the chained models around CMIP/PMIP mobility domains and the optimized routing paths in such context. The potential extensions should be applicable to both client-based/network-based and chained mobility models. * There were some issues that were raised around CP/DP separation and around the distributed deployment models. There should be analysis on the issues around such deployment models, in relation to centralized models that are deployed today. If the charter text broadly allows for some work around this, probably it should be fine. Finally, glad to see this work not defining a new protocol suite. But bringing value to the existing protocols. Regards Sri On 1/11/11 2:54 AM, "Jari Arkko" wrote: > All, > > I have been thinking about what to do about the distributed mobility > work since our meeting in Beijing. My suggestion is to add a work item > to the MEXT charter. Here's the proposed new item: > > Jari > > > Mobility EXTensions for IPv6 (mext) > ----------------------------------- > > Current Status: Active > > Chairs: > Marcelo Bagnulo > Julien Laganier > > Internet Area Directors: > Ralph Droms > Jari Arkko > > Internet Area Advisor: > Jari Arkko > > Mailing Lists: > General Discussion: mext@ietf.org > To Subscribe: https://www.ietf.org/mailman/listinfo/mext > Archive: http://www.ietf.org/mail-archive/web/mext > > Description of Working Group: > > Mobile IPv6 specifies routing support which permits an IPv6 host to > continue using its home address as it moves around the Internet, > enabling continuity of sessions. Mobile IPv6 supports transparency above > the IP layer, including maintenance of active transport level sessions. > In addition, network mobility (NEMO) mechanisms built on top of Mobile > IPv6 allow managing the mobility of an entire network, as it changes its > point of attachment to the Internet. The base specifications consist of: > > o RFC 3775 (Mobile IPv6) > o RFC 3963 (NEMO) > o RFC 4877 (Mobile IPv6 Operation with IKEv2) > o RFC 5555 (Dual Stack Mobile IPv6) > o RFC 5648 (Multiple Care-of Addresses Registration) > o RFC 5846 (Binding Revocation) > o RFC-to-be (Flow Binding Policy Transport and Flow Binding Policy Format) > > The MEXT Working Group continues the work of the former MIP6, NEMO, and > MONAMI6 Working Groups. > > The primary goal of MEXT will be to enhance base IPv6 mobility by > continuing work on developments that are required for wide-scale > deployments and specific deployment scenarios. Additionally, the working > group will ensure that any issues identified by implementation and > interoperability experience are addressed, and that the base > specifications are maintained. The group will also produce informational > documentation, such as design rationale documents or description of > specific issues within the protocol. > > The MEXT WG will also explore experimental alternative security > mechanisms. The security mechanism specified in the existing standard > track RFCs (RFC3775bis, RFC4877) remains the mandatory to implement > mechanism that guarantees interoperability between different > implementations. The MEXT WG is chartered to deliver one or more > experimental alternative mechanisms. All the alternative solutions will > be published as experimental RFCs. > > The working group will also work on operational considerations on > setting up Mobile IPv6 networks so that traffic is distributed > in an optimal way, for instance by using existing protocol mechanisms > to select the closest home agents for new clients. > > In addition, the working group will bring to completion earlier work on > prefix delegation for NEMO, RADIUS support for Mobile IPv6, Mobile IPv6 > operation with firewalls, and home agent reliability specifications. > > Work items related to base specification maintenance include: Create and > maintain issue lists that are generated on the basis of implementation > and interoperability experience. Address specific issues with specific > updates or revisions of the base specification. Currently known specific > issues include support for overlapping (private) IPv4 home addresses, > negotiation of the protection required for payload traffic, and > discovery of the home agent address in IPv4-only networks. > > > Goals and Milestones: > Jun 2011 - Submit I-D 'Mobile IPv6 Operation with Firewalls' to IESG for > publication as Informational. > Jun 2011 - Submit I-D 'Home agent reliability' to IESG for publication as a > Proposed Standard. > Aug 2011 - Submit I-Ds on alternative security mechanisms to the IESG for > publication as Experimental. > Sep 2011 - Submit I-D 'Overlapping IPv4 address support' to IESG for > publication as Proposed Standard. > Sep 2011 - Submit I-D 'Home agent discovery in IPv4-only networks via DHCP' > to IESG for publication as Proposed Standard. > Oct 2011 - Submit I-D 'Operational considerations for distributed use of > Mobile IPv6' for publication as Informational > Dec 2011 - Submit I-D 'Negotiation of the protection for payload traffic' to > IESG for publication as Proposed Standard. > Dec 2011 - Submit the I-D 'RADIUS Mobile IPv6 Support' to IESG for > publication as a proposed standard. > > > > charterjan2011.txt charterjan2011withdmm.txt > > skipping to change at line 60 skipping to change at line 60 > specific issues within the protocol. specific issues within the protocol. > > The MEXT WG will also explore experimental alternative security The MEXT > WG will also explore experimental alternative security > mechanisms. The security mechanism specified in the existing standard > mechanisms. The security mechanism specified in the existing standard > track RFCs (RFC3775bis, RFC4877) remains the mandatory to implement track > RFCs (RFC3775bis, RFC4877) remains the mandatory to implement > mechanism that guarantees interoperability between different mechanism > that guarantees interoperability between different > implementations. The MEXT WG is chartered to deliver one or more > implementations. The MEXT WG is chartered to deliver one or more > experimental alternative mechanisms. All the alternative solutions will > experimental alternative mechanisms. All the alternative solutions will > be published as experimental RFCs. be published as experimental RFCs. > > > The working group will also work on operational considerations on > setting up Mobile IPv6 networks so that traffic is distributed > in an optimal way, for instance by using existing protocol mechanisms > to select the closest home agents for new clients. > > In addition, the working group will bring to completion earlier work on In > addition, the working group will bring to completion earlier work on > prefix delegation for NEMO, RADIUS support for Mobile IPv6, Mobile IPv6 > prefix delegation for NEMO, RADIUS support for Mobile IPv6, Mobile IPv6 > operation with firewalls, and home agent reliability specifications. > operation with firewalls, and home agent reliability specifications. > > Work items related to base specification maintenance include: Create and > Work items related to base specification maintenance include: Create and > maintain issue lists that are generated on the basis of implementation > maintain issue lists that are generated on the basis of implementation > and interoperability experience. Address specific issues with specific and > interoperability experience. Address specific issues with specific > updates or revisions of the base specification. Currently known specific > updates or revisions of the base specification. Currently known specific > issues include support for overlapping (private) IPv4 home addresses, > issues include support for overlapping (private) IPv4 home addresses, > negotiation of the protection required for payload traffic, and > negotiation of the protection required for payload traffic, and > discovery of the home agent address in IPv4-only networks. discovery of > the home agent address in IPv4-only networks. > > Goals and Milestones: Goals and Milestones: > > Done - Submit I-D 'Mobile IPv6 Vendor Specific Option' to IESG for > publication as a Proposed Standard Jun 2011 - Submit I-D 'Mobile IPv6 > Operation with Firewalls' to IESG for publication as Informational. > Done - Submit I-D 'Mobile IPv6 Experimental Allocations' to IESG for > publication as a Proposed Standard Jun 2011 - Submit I-D 'Home agent > reliability' to IESG for publication as a Proposed Standard. > Done - Submit I-D 'Mobile IPv6 Dual-Stack Operation' to IESG for > publication as a Proposed Standard. > Done - Submit I-D 'Motivation for Authentication I-D' to IESG for > publication as Informational. > Done - Submit Multiple CoA Registration to IESG > Done - Submit I-D 'Goals for AAA HA Interface' to IESG for publication > as Informational. > Done - Submit -00 draft on Route Optimization Needs for Automobile and > Highway Deployments > Done - Submit -00 draft on Route Optimization Needs for Aircraft and > Spacecraft Deployments > Done - Submit I-D 'Mobility Header Home Agent Switch Message' to IESG > for publication as a Proposed Standard > Done - Submit final doc on Route Optimization Needs for Aircraft and > Spacecraft Deployments, for Informational > Done - Submit 00 draft on Binding Revocation > Done - Submit the final doc on MIB for NEMO Basic Support to the IESG, > for Proposed Standard > Done - Submit draft on Binding Revocation to IESG > Done - Submit I-D(s) related to specific updates and corrections of RFC > 3775 to IESG for publication as Proposed Standard. > Done - Submit the final doc on Prefix Delegation for NEMO to the IESG, > for Proposed Standard > Dec 2010 - Submit the I-D 'RADIUS Mobile IPv6 Support' to IESG for > publication as a proposed standard. > Jan 2011 - Submit I-D 'Mobile IPv6 Operation with Firewalls' to IESG for > publication as Informational. > Jan 2011 - Submit I-D 'Home agent reliability' to IESG for publication as a > Proposed Standard. > Aug 2011 - Submit I-Ds on alternative security mechanisms to the IESG for > publication as Experimental. Aug 2011 - Submit I-Ds on alternative security > mechanisms to the IESG for publication as Experimental. > Sep 2011 - Submit I-D 'Overlapping IPv4 address support' to IESG for > publication as Proposed Standard. Sep 2011 - Submit I-D 'Overlapping IPv4 > address support' to IESG for publication as Proposed Standard. > Sep 2011 - Submit I-D 'Home agent discovery in IPv4-only networks via DHCP' > to IESG for publication as Proposed Standard. Sep 2011 - Submit I-D 'Home > agent discovery in IPv4-only networks via DHCP' to IESG for publication as > Proposed Standard. > > Oct 2011 - Submit I-D 'Operational considerations for distributed use of > Mobile IPv6' for publication as Informational > Dec 2011 - Submit I-D 'Negotiation of the protection for payload traffic' to > IESG for publication as Proposed Standard. Dec 2011 - Submit I-D > 'Negotiation of the protection for payload traffic' to IESG for publication as > Proposed Standard. > > Dec 2011 - Submit the I-D 'RADIUS Mobile IPv6 Support' to IESG for > publication as a proposed standard. > > End of changes. 4 change blocks. > 18 lines changed or deleted 8 lines changed or added > This html diff was produced by rfcdiff 1.32. The latest version is available > from http://www.levkowetz.com/ietf/tools/rfcdiff/ > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext --B_3378309246_16548777 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable Re: [MEXT] suggest charter item for distributed mobility work</TITLE= > </HEAD> <BODY> <FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:11pt= '>Hi Jari:<BR> <BR> Thanks for the updated charter text. This looks good to me. Just couple of = comments. <BR> <BR> </SPAN></FONT><UL><LI><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN= STYLE=3D'font-size:11pt'>The approach of closest home agent selection is one = aspect of the DMM proposal. I assumed it includes other aspects such as CP/D= P separation.  Does the charter text gives such provision for such exte= nsions ? </SPAN></FONT><LI><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STY= LE=3D'font-size:11pt'>The BOF discussed the chained models around CMIP/PMIP mo= bility domains and the optimized routing paths in such context. The potentia= l extensions should be applicable to both client-based/network-based and cha= ined mobility models. </SPAN></FONT><LI><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STY= LE=3D'font-size:11pt'>There were some issues that were raised around CP/DP sep= aration and around the distributed deployment models. There should be analys= is on the issues around such deployment models, in relation to centralized m= odels that are deployed today.<BR> </SPAN></FONT></UL><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN ST= YLE=3D'font-size:11pt'><BR> If the charter text broadly allows for some work around this, probably it s= hould be fine. Finally, glad to see this work not defining a new protocol su= ite. But bringing value to the existing protocols.<BR> <BR> <BR> Regards<BR> Sri<BR> <BR> <BR> On 1/11/11 2:54 AM, "Jari Arkko" <<a href=3D"jari.arkko@piuha.ne= t">jari.arkko@piuha.net</a>> wrote:<BR> <BR> </SPAN></FONT><BLOCKQUOTE><FONT SIZE=3D"2"><FONT FACE=3D"Consolas, Courier New,= Courier"><SPAN STYLE=3D'font-size:10pt'>All,<BR> <BR> I have been thinking about what to do about the distributed mobility <BR> work since our meeting in Beijing. My suggestion is to add a work item <BR> to the MEXT charter. Here's the proposed new item:<BR> <BR> Jari<BR> <BR> <HR ALIGN=3DCENTER SIZE=3D"3" WIDTH=3D"95%">Mobility EXTensions for IPv6 (mext)<B= R> -----------------------------------<BR> <BR>  Current Status: Active<BR> <BR>  Chairs:<BR>      Marcelo Bagnulo <<a href=3D"marcelo@it.uc3m.= es">marcelo@it.uc3m.es</a>><BR>      Julien Laganier <<a href=3D"julienl@qualcomm= .com">julienl@qualcomm.com</a>><BR> <BR>  Internet Area Directors:<BR>      Ralph Droms <<a href=3D"rdroms.ietf@gmail.co= m">rdroms.ietf@gmail.com</a>><BR>      Jari Arkko <<a href=3D"jari.arkko@piuha.net"= >jari.arkko@piuha.net</a>><BR> <BR>  Internet Area Advisor:<BR>      Jari Arkko <<a href=3D"jari.arkko@piuha.net"= >jari.arkko@piuha.net</a>><BR> <BR>  Mailing Lists:<BR>      General Discussion: <a href=3D"mext@ietf.org">m= ext@ietf.org</a><BR>      To Subscribe:      &= nbsp;<a href=3D"https://www.ietf.org/mailman/listinfo/mext">https://www.ietf.o= rg/mailman/listinfo/mext</a><BR>      Archive:       =      <a href=3D"http://www.ietf.org/mail-archive/web/= mext">http://www.ietf.org/mail-archive/web/mext</a><BR> <BR> Description of Working Group:<BR> <BR>   Mobile IPv6 specifies routing support which permits an IPv6 hos= t to<BR>   continue using its home address as it moves around the Internet= ,<BR>   enabling continuity of sessions. Mobile IPv6 supports transpare= ncy above<BR>   the IP layer, including maintenance of active transport level s= essions.<BR>   In addition, network mobility (NEMO) mechanisms built on top of= Mobile<BR>   IPv6 allow managing the mobility of an entire network, as it ch= anges its<BR>   point of attachment to the Internet. The base specifications co= nsist of:<BR> <BR>   o RFC 3775 (Mobile IPv6)<BR>   o RFC 3963 (NEMO)<BR>   o RFC 4877 (Mobile IPv6 Operation with IKEv2)<BR>   o RFC 5555 (Dual Stack Mobile IPv6)<BR>   o RFC 5648 (Multiple Care-of Addresses Registration)<BR>   o RFC 5846 (Binding Revocation)<BR>   o RFC-to-be (Flow Binding Policy Transport and Flow Binding Pol= icy Format)<BR> <BR>   The MEXT Working Group continues the work of the former MIP6, N= EMO, and<BR>   MONAMI6 Working Groups.<BR> <BR>   The primary goal of MEXT will be to enhance base IPv6 mobility = by<BR>   continuing work on developments that are required for wide-scal= e<BR>   deployments and specific deployment scenarios. Additionally, th= e working<BR>   group will ensure that any issues identified by implementation = and<BR>   interoperability experience are addressed, and that the base<BR= >   specifications are maintained. The group will also produce info= rmational<BR>   documentation, such as design rationale documents or descriptio= n of<BR>   specific issues within the protocol.<BR> <BR>   The MEXT WG will also explore experimental alternative security= <BR>   mechanisms. The security mechanism specified in the existing st= andard<BR>   track RFCs (RFC3775bis, RFC4877) remains the mandatory to imple= ment<BR>   mechanism that guarantees interoperability between different<BR= >   implementations. The MEXT WG is chartered to deliver one or mor= e<BR>   experimental alternative mechanisms. All the alternative soluti= ons will<BR>   be published as experimental RFCs.<BR> <BR>   The working group will also work on operational considerations = on<BR>   setting up Mobile IPv6 networks so that traffic is distributed = <BR>   in an optimal way, for instance by using existing protocol mech= anisms<BR>   to select the closest home agents for new clients.<BR> <BR>   In addition, the working group will bring to completion earlier= work on<BR>   prefix delegation for NEMO, RADIUS  support for Mobile IPv= 6, Mobile IPv6<BR>   operation with firewalls, and home agent reliability specificat= ions.<BR> <BR>   Work items related to base specification maintenance include: C= reate and<BR>   maintain issue lists that are generated on the basis of impleme= ntation<BR>   and interoperability experience. Address specific issues with s= pecific<BR>   updates or revisions of the base specification. Currently known= specific<BR>   issues include support for overlapping (private) IPv4 home addr= esses,<BR>   negotiation of the protection required for payload traffic, and= <BR>   discovery of the home agent address in IPv4-only networks.<BR> <BR> <BR> Goals and Milestones:<BR>   Jun 2011 - Submit I-D 'Mobile IPv6 Operation with Firewalls' to= IESG for publication as Informational.<BR>   Jun 2011 - Submit I-D 'Home agent reliability' to IESG for publ= ication as a Proposed Standard.<BR>   Aug 2011 - Submit I-Ds on alternative security mechanisms to th= e IESG for publication as Experimental.<BR>   Sep 2011 - Submit I-D 'Overlapping IPv4 address support' to IES= G for publication as Proposed Standard.<BR>   Sep 2011 - Submit I-D 'Home agent discovery in IPv4-only networ= ks via DHCP' to IESG for publication as Proposed Standard.<BR>   Oct 2011 - Submit I-D 'Operational considerations for distribut= ed use of Mobile IPv6' for publication as Informational<BR>   Dec 2011 - Submit I-D 'Negotiation of the protection for payloa= d traffic' to IESG for publication as Proposed Standard.<BR>   Dec 2011 - Submit the I-D 'RADIUS Mobile IPv6 Support' to IESG = for publication as a proposed standard.<BR> <BR> <HR ALIGN=3DCENTER SIZE=3D"3" WIDTH=3D"95%"></SPAN></FONT></FONT><FONT FACE=3D"Cali= bri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:11pt'>   &n= bsp;        <BR>  charterjan2011.txt   charterjan2011withdmm.txt   = <BR>   <BR> skipping to change at<I> line 60</I> skipping to change at<I> line 60</I> <= BR>   specific issues within the protocol.   specific issue= s within the protocol. <BR>   <BR>   The MEXT WG will also explore experimental alternative security=   The MEXT WG will also explore experimental alternative security= <BR>   mechanisms. The security mechanism specified in the existing st= andard   mechanisms. The security mechanism specified in the exist= ing standard <BR>   track RFCs (RFC3775bis, RFC4877) remains the mandatory to imple= ment   track RFCs (RFC3775bis, RFC4877) remains the mandatory to i= mplement <BR>   mechanism that guarantees interoperability between different &n= bsp; mechanism that guarantees interoperability between different <BR>   implementations. The MEXT WG is chartered to deliver one or mor= e   implementations. The MEXT WG is chartered to deliver one or mo= re <BR>   experimental alternative mechanisms. All the alternative soluti= ons will   experimental alternative mechanisms. All the alternativ= e solutions will <BR>   be published as experimental RFCs.   be published as = experimental RFCs. <BR>   <BR>  <BR>    The working group will also work on operational considera= tions on <BR>    setting up Mobile IPv6 networks so that traffic is distri= buted <BR>    in an optimal way, for instance by using existing protoco= l mechanisms <BR>    to select the closest home agents for new clients. <BR>             &nb= sp;            &= nbsp;            = ;            &nb= sp;            &= nbsp;           <BR>   In addition, the working group will bring to completion earlier= work on   In addition, the working group will bring to completion= earlier work on <BR>   prefix delegation for NEMO, RADIUS  support for Mobile IPv= 6, Mobile IPv6   prefix delegation for NEMO, RADIUS  support = for Mobile IPv6, Mobile IPv6 <BR>   operation with firewalls, and home agent reliability specificat= ions.   operation with firewalls, and home agent reliability speci= fications. <BR>   <BR>   Work items related to base specification maintenance include: C= reate and   Work items related to base specification maintenance i= nclude: Create and <BR>   maintain issue lists that are generated on the basis of impleme= ntation   maintain issue lists that are generated on the basis of = implementation <BR>   and interoperability experience. Address specific issues with s= pecific   and interoperability experience. Address specific issues= with specific <BR>   updates or revisions of the base specification. Currently known= specific   updates or revisions of the base specification. Curren= tly known specific <BR>   issues include support for overlapping (private) IPv4 home addr= esses,   issues include support for overlapping (private) IPv4 hom= e addresses, <BR>   negotiation of the protection required for payload traffic, and=   negotiation of the protection required for payload traffic, and= <BR>   discovery of the home agent address in IPv4-only networks. &nbs= p; discovery of the home agent address in IPv4-only networks. <BR>   <BR> Goals and Milestones: Goals and Milestones: <BR>  <BR>   Done     - Submit I-D 'Mobile IPv6 Vendor S= pecific Option' to IESG for publication as a Proposed Standard   J= un 2011 - Submit I-D 'Mobile IPv6 Operation with Firewalls' to IESG for publ= ication as Informational. <BR>   Done     - Submit I-D 'Mobile IPv6 Experime= ntal Allocations' to IESG for publication as a Proposed Standard   = ;Jun 2011 - Submit I-D 'Home agent reliability' to IESG for publication as a= Proposed Standard. <BR>   Done     - Submit I-D 'Mobile IPv6 Dual-Sta= ck Operation' to IESG for publication as a Proposed Standard.  <BR>   Done     - Submit I-D 'Motivation for Authe= ntication I-D' to IESG for publication as Informational.  <BR>   Done     - Submit Multiple CoA Registration= to IESG  <BR>   Done     - Submit I-D 'Goals for AAA HA Int= erface' to IESG for publication as Informational.  <BR>   Done     - Submit -00 draft on Route Optimi= zation Needs for Automobile and Highway Deployments  <BR>   Done     - Submit -00 draft on Route Optimi= zation Needs for Aircraft and Spacecraft Deployments  <BR>   Done     - Submit I-D 'Mobility Header Home= Agent Switch Message' to IESG for publication as a Proposed Standard  = <BR>   Done     - Submit final doc on Route Optimi= zation Needs for Aircraft and Spacecraft Deployments, for Informational &nbs= p;<BR>   Done     - Submit 00 draft on Binding Revoc= ation  <BR>   Done     - Submit the final doc on MIB for = NEMO Basic Support to the IESG, for Proposed Standard  <BR>   Done     - Submit draft on Binding Revocati= on to IESG  <BR>   Done     - Submit I-D(s) related to specifi= c updates and corrections of RFC 3775 to IESG for publication as Proposed St= andard.  <BR>   Done     - Submit the final doc on Prefix D= elegation for NEMO to the IESG, for Proposed Standard  <BR>   Dec 2010 - Submit the I-D 'RADIUS Mobile IPv6 Support' to IESG = for publication as a proposed standard.  <BR>   Jan 2011 - Submit I-D 'Mobile IPv6 Operation with Firewalls' to= IESG for publication as Informational.  <BR>   Jan 2011 - Submit I-D 'Home agent reliability' to IESG for publ= ication as a Proposed Standard.  <BR>   Aug 2011 - Submit I-Ds on alternative security mechanisms to th= e IESG for publication as Experimental.   Aug 2011 - Submit I-Ds o= n alternative security mechanisms to the IESG for publication as Experimenta= l. <BR>   Sep 2011 - Submit I-D 'Overlapping IPv4 address support' to IES= G for publication as Proposed Standard.   Sep 2011 - Submit I-D 'O= verlapping IPv4 address support' to IESG for publication as Proposed Standar= d. <BR>   Sep 2011 - Submit I-D 'Home agent discovery in IPv4-only networ= ks via DHCP' to IESG for publication as Proposed Standard.   Sep 2= 011 - Submit I-D 'Home agent discovery in IPv4-only networks via DHCP' to IE= SG for publication as Proposed Standard. <BR>  <BR>    Oct 2011 - Submit I-D 'Operational considerations for dis= tributed use of Mobile IPv6' for publication as Informational <BR>   Dec 2011 - Submit I-D 'Negotiation of the protection for payloa= d traffic' to IESG for publication as Proposed Standard.   Dec 201= 1 - Submit I-D 'Negotiation of the protection for payload traffic' to IESG f= or publication as Proposed Standard. <BR>  <BR>    Dec 2011 - Submit the I-D 'RADIUS Mobile IPv6 Support' to= IESG for publication as a proposed standard.  <BR>   <BR>  End of changes. 4 change blocks.  <BR> <I>18 lines changed or deleted 8 lines changed or added</I> <BR> </SPAN></FONT><SPAN STYLE=3D'font-size:11pt'><FONT FACE=3D"Verdana, Helvetica, = Arial">This html diff was produced by rfcdiff 1.32. The latest version is av= ailable from <a href=3D"http://www.levkowetz.com/ietf/tools/rfcdiff/">http://w= ww.levkowetz.com/ietf/tools/rfcdiff/</a> </FONT><FONT FACE=3D"Calibri, Verdana= , Helvetica, Arial">   <BR> <HR ALIGN=3DCENTER SIZE=3D"3" WIDTH=3D"95%"></FONT></SPAN><FONT SIZE=3D"2"><FONT FA= CE=3D"Consolas, Courier New, Courier"><SPAN STYLE=3D'font-size:10pt'>___________= ____________________________________<BR> MEXT mailing list<BR> <a href=3D"MEXT@ietf.org">MEXT@ietf.org</a><BR> <a href=3D"https://www.ietf.org/mailman/listinfo/mext">https://www.ietf.org/m= ailman/listinfo/mext</a><BR> </SPAN></FONT></FONT></BLOCKQUOTE> </BODY> </HTML> --B_3378309246_16548777-- From jan@go6.si Thu Jan 20 00:31:41 2011 Return-Path: <jan@go6.si> X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C99813A70AF for <mext@core3.amsl.com>; Thu, 20 Jan 2011 00:31:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zdj7AEHnxsej for <mext@core3.amsl.com>; Thu, 20 Jan 2011 00:31:37 -0800 (PST) Received: from ipv6.go6.si (go6.si [212.44.108.1]) by core3.amsl.com (Postfix) with ESMTP id 239E53A6E7E for <mext@ietf.org>; Thu, 20 Jan 2011 00:31:37 -0800 (PST) Received: from jan-mac.local (unknown [IPv6:2001:470:d422:1:1293:e9ff:fe07:182c]) (Authenticated sender: jan) by ipv6.go6.si (Postfix) with ESMTP id F209A2378033 for <mext@ietf.org>; Thu, 20 Jan 2011 09:34:14 +0100 (CET) Message-ID: <4D37F38A.4080602@go6.si> Date: Thu, 20 Jan 2011 09:34:18 +0100 From: "Jan Zorz @ go6.si" <jan@go6.si> User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: mext@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [MEXT] Review of I-D draft-korhonen-mext-mip6-altsec-06 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG <mext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/mext> List-Post: <mailto:mext@ietf.org> List-Help: <mailto:mext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 20 Jan 2011 08:31:42 -0000 Hi, It took me quite long to write this review, but finally, here it is :) Review comments: In general the proposal of using an alternative to IPsec and IKEv2 seems quite okay. The main purpose of Mobile IPv6 is to enable mobility at the IP layer and hence using TLS which is much more widely implemented and deployed for use to secure the signaling is good. More specific comments: - The proposal introduces a new element called HAC. In terms of deployments such a network element may become central for bootstrapping Mobile IPv6. The I-D states that the HAC could be co-located with the HA. In reality, the HAC should be a standalone entity which interacts with AAA and policy engines in a network. - TLS is widely used for security in the Internet today. Hence the use of TLS does not weaken mobile IPv6 security. TLS is also used only for bootstrapping and not for securing the signaling or traffic. - Describe the steps in figure 1. - The security association scope says that it describes whether the SA is only for signaling or for data as well. Would be useful to make it more explicit. - Route optimization is an important feature of Mobile IPv6. Hence this alternate security solution should explain how the route optimization signaling messages are secured. - Unclear why HTTP headers (Sec 8.2) are being reserved. Could not really understand the purpose. - Message details are fairly complete and hence should be implementable. In summary, the draft is well written and complete and should be considered for standardization. I'm using DSMIP6-TLS implementations on N900 phone and Ubuntu Linux laptop in everyday life and it seems to work quite well. There are still some implementation issues that needs to be fixed, but overall feeling is very satisfactory. Regards, Jan Zorz go6.si From jouni.nospam@gmail.com Thu Jan 20 01:28:31 2011 Return-Path: <jouni.nospam@gmail.com> X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF0D73A7212 for <mext@core3.amsl.com>; Thu, 20 Jan 2011 01:28:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BkrPESnir+sf for <mext@core3.amsl.com>; Thu, 20 Jan 2011 01:28:30 -0800 (PST) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by core3.amsl.com (Postfix) with ESMTP id 3DB093A7103 for <mext@ietf.org>; Thu, 20 Jan 2011 01:28:30 -0800 (PST) Received: by eyd10 with SMTP id 10so141026eyd.31 for <mext@ietf.org>; Thu, 20 Jan 2011 01:31:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=VNBrv3m2pBtQve9Qd5fmuzn8f0B1zYgAfzTNrHdTmZw=; b=CRm+SR7Z9fL0FBTg2Wc3f/6STMRwR7vc7nLa8IXQJLWPuIf7+r0fNLdEaabrAM+inA NjGlmjMZuPLuNJUJNcEzqOPU56ufMO9q6nfBCHTNgnVrjkDE7LVijMdWnYWWCdsb0wOH o3pTbPtMJUDVoBbK1rO0ldKvrbmB8HC2JnRCU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=O/4oUCJif1jVYutyEnEF0jEVPdhMnhF6Ki5MX2KEep2Mciv0rlA2b/r0s/9l6nuNeF GcqwsYP5w5x0Vzsvg9sm0CpFi3hqwAB9o8I56vY/GG1OV1UmnrUsC97vUx2T/Nv6ulnB vrndPmDFBDzBGpOfw+A3ArDgKfsoDHC4jwsTM= Received: by 10.213.19.20 with SMTP id y20mr2585198eba.75.1295515871893; Thu, 20 Jan 2011 01:31:11 -0800 (PST) Received: from [192.168.141.77] ([213.246.198.210]) by mx.google.com with ESMTPS id b52sm6385783eei.7.2011.01.20.01.31.09 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 20 Jan 2011 01:31:10 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: jouni korhonen <jouni.nospam@gmail.com> In-Reply-To: <4D37F38A.4080602@go6.si> Date: Thu, 20 Jan 2011 11:31:08 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <B96E2661-6C08-46A1-9C3D-915D604DDF0B@gmail.com> References: <4D37F38A.4080602@go6.si> To: Jan Zorz @ go6.si <jan@go6.si> X-Mailer: Apple Mail (2.1078) Cc: mext@ietf.org Subject: Re: [MEXT] Review of I-D draft-korhonen-mext-mip6-altsec-06 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG <mext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/mext> List-Post: <mailto:mext@ietf.org> List-Help: <mailto:mext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 20 Jan 2011 09:28:32 -0000 Hi Jan, Thanks for the review! We will reflect these along those comments = received from Ryuji and Domagoj. Some more detailed comments inline. On Jan 20, 2011, at 10:34 AM, Jan Zorz @ go6.si wrote: > Hi, >=20 > It took me quite long to write this review, but finally, here it is :) >=20 > Review comments: >=20 > In general the proposal of using an alternative to IPsec and IKEv2 > seems quite okay. The main purpose of Mobile IPv6 is to enable > mobility at the IP layer and hence using TLS which is much more widely > implemented and deployed for use to secure the signaling is good. >=20 > More specific comments: >=20 > - The proposal introduces a new element called HAC. In terms of > deployments such a network element may become central for > bootstrapping Mobile IPv6. The I-D states that the HAC could be > co-located with the HA. In reality, the HAC should be a standalone > entity which interacts with AAA and policy engines in a network. That is purely an implementation issue. We will add some more text = around this topic. >=20 > - TLS is widely used for security in the Internet today. Hence the use > of TLS does not weaken mobile IPv6 security. TLS is also used only > for bootstrapping and not for securing the signaling or traffic. Right. However, bootstrapping agrees on ciphers that are available for = TLS and at the implementation level we then use those ciphers available = in TLS library. So in a way we still utilize TLS code base for signaling = & traffic ciphering. >=20 > - Describe the steps in figure 1. ok. >=20 > - The security association scope says that it describes whether the SA > is only for signaling or for data as well. Would be useful to make > it more explicit. Ok. >=20 > - Route optimization is an important feature of Mobile IPv6. Hence > this alternate security solution should explain how the route > optimization signaling messages are secured. Currently the I-D scopes route optimization out. That is stated at the = very end of the document though. We have been thinking to add route = optimization support though. >=20 > - Unclear why HTTP headers (Sec 8.2) are being reserved. Could not > really understand the purpose. Just a left over from earlier revisions. >=20 > - Message details are fairly complete and hence should be > implementable. >=20 > In summary, the draft is well written and complete and should be > considered for standardization. >=20 > I'm using DSMIP6-TLS implementations on N900 phone and Ubuntu Linux = laptop in everyday life and it seems to work quite well. There are still = some implementation issues that needs to be fixed, but overall feeling = is very satisfactory. >=20 Thanks. - Jouni > Regards, Jan Zorz > go6.si > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext From jan@go6.si Thu Jan 20 01:34:00 2011 Return-Path: <jan@go6.si> X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 85D183A7214 for <mext@core3.amsl.com>; Thu, 20 Jan 2011 01:34:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DLidRwhbPcuy for <mext@core3.amsl.com>; Thu, 20 Jan 2011 01:33:59 -0800 (PST) Received: from ipv6.go6.si (go6.si [212.44.108.1]) by core3.amsl.com (Postfix) with ESMTP id 8F2D53A7212 for <mext@ietf.org>; Thu, 20 Jan 2011 01:33:59 -0800 (PST) Received: from jan-mac.local (unknown [IPv6:2001:470:d422:1:1293:e9ff:fe07:182c]) (Authenticated sender: jan) by ipv6.go6.si (Postfix) with ESMTP id EC90A2378033; Thu, 20 Jan 2011 10:36:38 +0100 (CET) Message-ID: <4D380226.3020108@go6.si> Date: Thu, 20 Jan 2011 10:36:38 +0100 From: "Jan Zorz @ go6.si" <jan@go6.si> User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: jouni korhonen <jouni.nospam@gmail.com> References: <4D37F38A.4080602@go6.si> <B96E2661-6C08-46A1-9C3D-915D604DDF0B@gmail.com> In-Reply-To: <B96E2661-6C08-46A1-9C3D-915D604DDF0B@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mext@ietf.org Subject: Re: [MEXT] Review of I-D draft-korhonen-mext-mip6-altsec-06 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG <mext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/mext> List-Post: <mailto:mext@ietf.org> List-Help: <mailto:mext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 20 Jan 2011 09:34:00 -0000 On 1/20/11 10:31 AM, jouni korhonen wrote: >> - Route optimization is an important feature of Mobile IPv6. Hence >> this alternate security solution should explain how the route >> optimization signaling messages are secured. > > Currently the I-D scopes route optimization out. That is stated at > the very end of the document though. We have been thinking to add > route optimization support though. Jouni, hi. I think this is essential and *must* be in there. Of what use is all mobility stuff if there is no route optimization? I understand that mobile operators are a bit nervous about that, but this shouldn't be a reason not describing/defining route optimization in I-D and do it in implementation. Regards, Jan From arno@natisbad.org Thu Jan 20 01:42:25 2011 Return-Path: <arno@natisbad.org> X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24D803A70E7 for <mext@core3.amsl.com>; Thu, 20 Jan 2011 01:42:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qv7hHg177zAS for <mext@core3.amsl.com>; Thu, 20 Jan 2011 01:42:24 -0800 (PST) Received: from copper.chdir.org (copper.chdir.org [88.191.97.87]) by core3.amsl.com (Postfix) with ESMTP id 196593A6EAA for <mext@ietf.org>; Thu, 20 Jan 2011 01:42:23 -0800 (PST) Received: from enough (unknown [IPv6:2001:7a8:1161:20:baac:6fff:fe41:5166]) by copper.chdir.org (Postfix) with ESMTPSA id D2A05450053; Thu, 20 Jan 2011 10:40:03 +0100 (CET) From: arno@natisbad.org (Arnaud Ebalard) To: "Jan Zorz \@ go6.si" <jan@go6.si> References: <4D37F38A.4080602@go6.si> <B96E2661-6C08-46A1-9C3D-915D604DDF0B@gmail.com> <4D380226.3020108@go6.si> X-PGP-Key-URL: http://natisbad.org/arno@natisbad.org.asc X-Fingerprint: D3A5 B68A 839B 38A5 815A 781B B77C 0748 A7AE 341B X-Hashcash: 1:20:110120:mext@ietf.org::2iBb/C7AN5xQwZCQ:00000E1J X-Hashcash: 1:20:110120:jan@go6.si::k9wiBjsr3FopxTwY:00000000dyj X-Hashcash: 1:20:110120:jouni.nospam@gmail.com::mQE0oXiFd4IjUizy:0000000000000000000000000000000000000001CsI Date: Thu, 20 Jan 2011 10:35:08 +0100 In-Reply-To: <4D380226.3020108@go6.si> (Jan Zorz's message of "Thu, 20 Jan 2011 10:36:38 +0100") Message-ID: <87lj2f3okz.fsf@natisbad.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: jouni korhonen <jouni.nospam@gmail.com>, mext@ietf.org Subject: Re: [MEXT] Review of I-D draft-korhonen-mext-mip6-altsec-06 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG <mext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/mext> List-Post: <mailto:mext@ietf.org> List-Help: <mailto:mext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 20 Jan 2011 09:42:25 -0000 "Jan Zorz @ go6.si" <jan@go6.si> writes: > On 1/20/11 10:31 AM, jouni korhonen wrote: >>> - Route optimization is an important feature of Mobile IPv6. Hence >>> this alternate security solution should explain how the route >>> optimization signaling messages are secured. >> >> Currently the I-D scopes route optimization out. That is stated at >> the very end of the document though. We have been thinking to add >> route optimization support though. > > Jouni, hi. > > I think this is essential and *must* be in there. Of what use is all > mobility stuff if there is no route optimization? > > I understand that mobile operators are a bit nervous about that, but > this shouldn't be a reason not describing/defining route optimization > in I-D and do it in implementation. +1 From jari.arkko@piuha.net Thu Jan 20 10:22:40 2011 Return-Path: <jari.arkko@piuha.net> X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CEE4B3A704B; Thu, 20 Jan 2011 10:22:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.533 X-Spam-Level: X-Spam-Status: No, score=-102.533 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qg6WUCY7wNtV; Thu, 20 Jan 2011 10:22:36 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id D35FC3A7048; Thu, 20 Jan 2011 10:22:35 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 888A72CC31; Thu, 20 Jan 2011 20:25:18 +0200 (EET) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ILHUFyjDap5t; Thu, 20 Jan 2011 20:25:17 +0200 (EET) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 1C5932CC2D; Thu, 20 Jan 2011 20:25:15 +0200 (EET) Message-ID: <4D387E0C.8070200@piuha.net> Date: Thu, 20 Jan 2011 20:25:16 +0200 From: Jari Arkko <jari.arkko@piuha.net> User-Agent: Thunderbird 2.0.0.24 (X11/20101027) MIME-Version: 1.0 To: Sri Gundavelli <sgundave@cisco.com> References: <C95CE87E.D35B%sgundave@cisco.com> In-Reply-To: <C95CE87E.D35B%sgundave@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dmm@ietf.org, "mext@ietf.org" <mext@ietf.org> Subject: Re: [MEXT] suggest charter item for distributed mobility work X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG <mext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/mext> List-Post: <mailto:mext@ietf.org> List-Help: <mailto:mext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 20 Jan 2011 18:22:40 -0000 Sri, > Thanks for the updated charter text. This looks good to me. Just > couple of comments. > > * The approach of closest home agent selection is one aspect of > the DMM proposal. I assumed it includes other aspects such as > CP/DP separation. Does the charter text gives such provision > for such extensions ? > Yes. Its says "for instance". > * The BOF discussed the chained models around CMIP/PMIP mobility > domains and the optimized routing paths in such context. The > potential extensions should be applicable to both > client-based/network-based and chained mobility models. > I think anything in the area of operational guidance, or usage of existing protocols to do some form of distribution or optimized route paths would be fair game, IMO. > * There were some issues that were raised around CP/DP separation > and around the distributed deployment models. There should be > analysis on the issues around such deployment models, in > relation to centralized models that are deployed today. > Again, I think this is included. But I would rather not write all of this to the charter explicitly; we might miss some issues that we will in any case have to deal with in the documents. > If the charter text broadly allows for some work around this, probably > it should be fine. Finally, glad to see this work not defining a new > protocol suite. But bringing value to the existing protocols. Right. Jari > > > Regards > Sri > > > On 1/11/11 2:54 AM, "Jari Arkko" <jari.arkko@piuha.net> wrote: > > All, > > I have been thinking about what to do about the distributed mobility > work since our meeting in Beijing. My suggestion is to add a work > item > to the MEXT charter. Here's the proposed new item: > > Jari > > ------------------------------------------------------------------------ > Mobility EXTensions for IPv6 (mext) > ----------------------------------- > > Current Status: Active > > Chairs: > Marcelo Bagnulo <marcelo@it.uc3m.es> > Julien Laganier <julienl@qualcomm.com> > > Internet Area Directors: > Ralph Droms <rdroms.ietf@gmail.com> > Jari Arkko <jari.arkko@piuha.net> > > Internet Area Advisor: > Jari Arkko <jari.arkko@piuha.net> > > Mailing Lists: > General Discussion: mext@ietf.org > To Subscribe: https://www.ietf.org/mailman/listinfo/mext > Archive: http://www.ietf.org/mail-archive/web/mext > > Description of Working Group: > > Mobile IPv6 specifies routing support which permits an IPv6 host to > continue using its home address as it moves around the Internet, > enabling continuity of sessions. Mobile IPv6 supports > transparency above > the IP layer, including maintenance of active transport level > sessions. > In addition, network mobility (NEMO) mechanisms built on top of > Mobile > IPv6 allow managing the mobility of an entire network, as it > changes its > point of attachment to the Internet. The base specifications > consist of: > > o RFC 3775 (Mobile IPv6) > o RFC 3963 (NEMO) > o RFC 4877 (Mobile IPv6 Operation with IKEv2) > o RFC 5555 (Dual Stack Mobile IPv6) > o RFC 5648 (Multiple Care-of Addresses Registration) > o RFC 5846 (Binding Revocation) > o RFC-to-be (Flow Binding Policy Transport and Flow Binding > Policy Format) > > The MEXT Working Group continues the work of the former MIP6, > NEMO, and > MONAMI6 Working Groups. > > The primary goal of MEXT will be to enhance base IPv6 mobility by > continuing work on developments that are required for wide-scale > deployments and specific deployment scenarios. Additionally, the > working > group will ensure that any issues identified by implementation and > interoperability experience are addressed, and that the base > specifications are maintained. The group will also produce > informational > documentation, such as design rationale documents or description of > specific issues within the protocol. > > The MEXT WG will also explore experimental alternative security > mechanisms. The security mechanism specified in the existing > standard > track RFCs (RFC3775bis, RFC4877) remains the mandatory to implement > mechanism that guarantees interoperability between different > implementations. The MEXT WG is chartered to deliver one or more > experimental alternative mechanisms. All the alternative > solutions will > be published as experimental RFCs. > > The working group will also work on operational considerations on > setting up Mobile IPv6 networks so that traffic is distributed > in an optimal way, for instance by using existing protocol > mechanisms > to select the closest home agents for new clients. > > In addition, the working group will bring to completion earlier > work on > prefix delegation for NEMO, RADIUS support for Mobile IPv6, > Mobile IPv6 > operation with firewalls, and home agent reliability specifications. > > Work items related to base specification maintenance include: > Create and > maintain issue lists that are generated on the basis of > implementation > and interoperability experience. Address specific issues with > specific > updates or revisions of the base specification. Currently known > specific > issues include support for overlapping (private) IPv4 home > addresses, > negotiation of the protection required for payload traffic, and > discovery of the home agent address in IPv4-only networks. > > > Goals and Milestones: > Jun 2011 - Submit I-D 'Mobile IPv6 Operation with Firewalls' to > IESG for publication as Informational. > Jun 2011 - Submit I-D 'Home agent reliability' to IESG for > publication as a Proposed Standard. > Aug 2011 - Submit I-Ds on alternative security mechanisms to the > IESG for publication as Experimental. > Sep 2011 - Submit I-D 'Overlapping IPv4 address support' to IESG > for publication as Proposed Standard. > Sep 2011 - Submit I-D 'Home agent discovery in IPv4-only > networks via DHCP' to IESG for publication as Proposed Standard. > Oct 2011 - Submit I-D 'Operational considerations for > distributed use of Mobile IPv6' for publication as Informational > Dec 2011 - Submit I-D 'Negotiation of the protection for payload > traffic' to IESG for publication as Proposed Standard. > Dec 2011 - Submit the I-D 'RADIUS Mobile IPv6 Support' to IESG > for publication as a proposed standard. > > ------------------------------------------------------------------------ > > charterjan2011.txt charterjan2011withdmm.txt > > skipping to change at/ line 60/ skipping to change at/ line 60/ > specific issues within the protocol. specific issues within > the protocol. > > The MEXT WG will also explore experimental alternative security > The MEXT WG will also explore experimental alternative security > mechanisms. The security mechanism specified in the existing > standard mechanisms. The security mechanism specified in the > existing standard > track RFCs (RFC3775bis, RFC4877) remains the mandatory to > implement track RFCs (RFC3775bis, RFC4877) remains the mandatory > to implement > mechanism that guarantees interoperability between different > mechanism that guarantees interoperability between different > implementations. The MEXT WG is chartered to deliver one or more > implementations. The MEXT WG is chartered to deliver one or more > experimental alternative mechanisms. All the alternative > solutions will experimental alternative mechanisms. All the > alternative solutions will > be published as experimental RFCs. be published as > experimental RFCs. > > > The working group will also work on operational considerations on > setting up Mobile IPv6 networks so that traffic is distributed > in an optimal way, for instance by using existing protocol > mechanisms > to select the closest home agents for new clients. > > In addition, the working group will bring to completion earlier > work on In addition, the working group will bring to completion > earlier work on > prefix delegation for NEMO, RADIUS support for Mobile IPv6, > Mobile IPv6 prefix delegation for NEMO, RADIUS support for > Mobile IPv6, Mobile IPv6 > operation with firewalls, and home agent reliability > specifications. operation with firewalls, and home agent > reliability specifications. > > Work items related to base specification maintenance include: > Create and Work items related to base specification maintenance > include: Create and > maintain issue lists that are generated on the basis of > implementation maintain issue lists that are generated on the > basis of implementation > and interoperability experience. Address specific issues with > specific and interoperability experience. Address specific > issues with specific > updates or revisions of the base specification. Currently known > specific updates or revisions of the base specification. > Currently known specific > issues include support for overlapping (private) IPv4 home > addresses, issues include support for overlapping (private) IPv4 > home addresses, > negotiation of the protection required for payload traffic, and > negotiation of the protection required for payload traffic, and > discovery of the home agent address in IPv4-only networks. > discovery of the home agent address in IPv4-only networks. > > Goals and Milestones: Goals and Milestones: > > Done - Submit I-D 'Mobile IPv6 Vendor Specific Option' to > IESG for publication as a Proposed Standard Jun 2011 - Submit > I-D 'Mobile IPv6 Operation with Firewalls' to IESG for publication > as Informational. > Done - Submit I-D 'Mobile IPv6 Experimental Allocations' to > IESG for publication as a Proposed Standard Jun 2011 - Submit > I-D 'Home agent reliability' to IESG for publication as a Proposed > Standard. > Done - Submit I-D 'Mobile IPv6 Dual-Stack Operation' to IESG > for publication as a Proposed Standard. > Done - Submit I-D 'Motivation for Authentication I-D' to > IESG for publication as Informational. > Done - Submit Multiple CoA Registration to IESG > Done - Submit I-D 'Goals for AAA HA Interface' to IESG for > publication as Informational. > Done - Submit -00 draft on Route Optimization Needs for > Automobile and Highway Deployments > Done - Submit -00 draft on Route Optimization Needs for > Aircraft and Spacecraft Deployments > Done - Submit I-D 'Mobility Header Home Agent Switch > Message' to IESG for publication as a Proposed Standard > Done - Submit final doc on Route Optimization Needs for > Aircraft and Spacecraft Deployments, for Informational > Done - Submit 00 draft on Binding Revocation > Done - Submit the final doc on MIB for NEMO Basic Support to > the IESG, for Proposed Standard > Done - Submit draft on Binding Revocation to IESG > Done - Submit I-D(s) related to specific updates and > corrections of RFC 3775 to IESG for publication as Proposed > Standard. > Done - Submit the final doc on Prefix Delegation for NEMO to > the IESG, for Proposed Standard > Dec 2010 - Submit the I-D 'RADIUS Mobile IPv6 Support' to IESG > for publication as a proposed standard. > Jan 2011 - Submit I-D 'Mobile IPv6 Operation with Firewalls' to > IESG for publication as Informational. > Jan 2011 - Submit I-D 'Home agent reliability' to IESG for > publication as a Proposed Standard. > Aug 2011 - Submit I-Ds on alternative security mechanisms to the > IESG for publication as Experimental. Aug 2011 - Submit I-Ds on > alternative security mechanisms to the IESG for publication as > Experimental. > Sep 2011 - Submit I-D 'Overlapping IPv4 address support' to IESG > for publication as Proposed Standard. Sep 2011 - Submit I-D > 'Overlapping IPv4 address support' to IESG for publication as > Proposed Standard. > Sep 2011 - Submit I-D 'Home agent discovery in IPv4-only > networks via DHCP' to IESG for publication as Proposed Standard. > Sep 2011 - Submit I-D 'Home agent discovery in IPv4-only > networks via DHCP' to IESG for publication as Proposed Standard. > > Oct 2011 - Submit I-D 'Operational considerations for > distributed use of Mobile IPv6' for publication as Informational > Dec 2011 - Submit I-D 'Negotiation of the protection for payload > traffic' to IESG for publication as Proposed Standard. Dec 2011 > - Submit I-D 'Negotiation of the protection for payload traffic' > to IESG for publication as Proposed Standard. > > Dec 2011 - Submit the I-D 'RADIUS Mobile IPv6 Support' to IESG > for publication as a proposed standard. > > End of changes. 4 change blocks. > /18 lines changed or deleted 8 lines changed or added/ > This html diff was produced by rfcdiff 1.32. The latest version is > available from http://www.levkowetz.com/ietf/tools/rfcdiff/ > ------------------------------------------------------------------------ > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > From jari.arkko@piuha.net Thu Jan 20 10:57:36 2011 Return-Path: <jari.arkko@piuha.net> X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5EF5F3A6452; Thu, 20 Jan 2011 10:57:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.534 X-Spam-Level: X-Spam-Status: No, score=-102.534 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZszjAG4se2id; Thu, 20 Jan 2011 10:57:35 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 7C1583A6407; Thu, 20 Jan 2011 10:57:35 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 8A6A82CC31; Thu, 20 Jan 2011 21:00:18 +0200 (EET) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4YDCrRPQzvhD; Thu, 20 Jan 2011 21:00:18 +0200 (EET) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id A1E472CC2D; Thu, 20 Jan 2011 21:00:17 +0200 (EET) Message-ID: <4D388641.7060405@piuha.net> Date: Thu, 20 Jan 2011 21:00:17 +0200 From: Jari Arkko <jari.arkko@piuha.net> User-Agent: Thunderbird 2.0.0.24 (X11/20101027) MIME-Version: 1.0 To: "mext@ietf.org" <mext@ietf.org> References: <C95CE87E.D35B%sgundave@cisco.com> In-Reply-To: <C95CE87E.D35B%sgundave@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dmm@ietf.org Subject: Re: [MEXT] suggest charter item for distributed mobility work X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG <mext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/mext> List-Post: <mailto:mext@ietf.org> List-Help: <mailto:mext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 20 Jan 2011 18:57:36 -0000 The IESG has approved the change to the charter in our telechat today. Jari From georg.hampel@alcatel-lucent.com Thu Jan 20 12:04:28 2011 Return-Path: <georg.hampel@alcatel-lucent.com> X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B9793A67EF for <mext@core3.amsl.com>; Thu, 20 Jan 2011 12:04:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ddEco8q5qwfK for <mext@core3.amsl.com>; Thu, 20 Jan 2011 12:04:20 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by core3.amsl.com (Postfix) with ESMTP id A80743A67EB for <mext@ietf.org>; Thu, 20 Jan 2011 12:04:20 -0800 (PST) Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id p0KK73XJ006400 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <mext@ietf.org>; Thu, 20 Jan 2011 14:07:04 -0600 (CST) Received: from USNAVSXCHHUB02.ndc.alcatel-lucent.com (usnavsxchhub02.ndc.alcatel-lucent.com [135.3.39.111]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p0KK732r018325 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for <mext@ietf.org>; Thu, 20 Jan 2011 14:07:03 -0600 Received: from USNAVSXCHMBSA2.ndc.alcatel-lucent.com ([135.3.39.127]) by USNAVSXCHHUB02.ndc.alcatel-lucent.com ([135.3.39.111]) with mapi; Thu, 20 Jan 2011 14:07:03 -0600 From: "Hampel, K Georg (K Georg)" <georg.hampel@alcatel-lucent.com> To: "mext@ietf.org" <mext@ietf.org> Date: Thu, 20 Jan 2011 14:07:01 -0600 Thread-Topic: Support of route optimization in *absence* of HA Thread-Index: Acu43ZmfXvNW17TRRju54k2cv8RwfQ== Message-ID: <154773479ED2314980CB638A48FC44348334CE4F@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_154773479ED2314980CB638A48FC44348334CE4FUSNAVSXCHMBSA2n_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.9 Cc: "Hampel, K Georg \(K Georg\)" <georg.hampel@alcatel-lucent.com>, "Klein, Thierry E \(Thierry\)" <thierry.klein@alcatel-lucent.com> Subject: [MEXT] Support of route optimization in *absence* of HA X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG <mext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/mext> List-Post: <mailto:mext@ietf.org> List-Help: <mailto:mext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 20 Jan 2011 20:04:28 -0000 --_000_154773479ED2314980CB638A48FC44348334CE4FUSNAVSXCHMBSA2n_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, We would like to add a proposal to MEXT that permits the mobile to engage i= nto route-optimization in *absence* of a home agent. Such a feature adds robustness to route optimization in case the HA is temp= orarily unavailable. Under some circumstances, route optimization *without*= HA may be beneficial for performance reasons. Our proposal requires "enhan= ced route optimization for Mobile IPv6" (RFC 4866) as pre-requisite. We would like to obtain some feedback from the MEXT community via this mail= ing list before we submit the proposal as a draft to the workgroup. For thi= s purpose, we have enclosed a high-level outline below. Thanks. Regards, Georg Hampel Networking & Networks Domain Bell Laboratories Alcatel-Lucent =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Proposal: Support of Route-Optimization in Absence of Home Agent ABSTRACT: The proposal allows the mobile to engage into route optimization (R/O) in *= absence* of a HA. This feature increases robustness when the HA becomes tem= porarily unavailable. Under some circumstances, R/O *without* HA may be ben= eficial for performance reasons. This proposal requires "enhanced route opt= imization for Mobile IPv6" (RFC 4866) as pre-requisite. MOTIVATION: In route optimization (R/O), traffic packets are directly exchanged between= hosts without passing the HA. The mobile, however, still has to interact w= ith the HA. The HA provides (1) location service, (2) a fallback path in ca= se the direct path breaks, (3) a fallback in case the correspondent does no= t support the protocol and (4) security support for R/O-related signaling (= i.e. home test). These functions come at the following cost: * Handovers may fail when the link to the HA or the HA itself are dow= n or congested. Mobility is not supported, when the mobile does not have a = HA. * When the mobile starts a session outside of its home network, it mu= st use a HoA pertaining to its home network even if it engages into R/O. Th= is requirement adds air-interface overhead due to mobility headers and proc= essing overhead on the mobile. This upfront cost incurs even if the mobile = does not move during the session. * Signaling handshakes have to be conducted between mobile and HA at = every mobility event. Currently, the Mobile IPv6 standard family forces the mobile to bear these = disadvantages in R/O even if the HA functions are not needed. This specific= ally applies to scenarios where: * Traffic is based on mobile-initiated requests to public servers (ma= jority of present mobile internet traffic). The HA's location service is no= t needed for such traffic. Location service may also be provided by other m= eans such as Dynamic DNS or on application layer (e.g. SIP registrar). * The fallback path through the HA has little value when it shares th= e weakest link with the direct path. Since the weakest link is typically th= e wireless link, this situation applies to all scenarios where only one air= interface is available (this is the typical case rather than the exception= ). * The mobile may know about the correspondent's Mobile-IPv6 support f= rom prior sessions or through means external to the standard. * The mobile applies the CGA-based procedure of RFC 4866, which makes= the HA's security support for R/O unnecessary. This applies to all cases w= here stateless addressing is permitted. To increase the flexibility and robustness of route-optimized Mobile IPv6, = we propose to make the HA an *optional* rather than a *mandatory* feature, = i.e. to permit operation without HA. This proposal requires some additional= extensions to the present standard. HIGH-LEVEL OUTLINE The extensions build on Enhanced Route Optimization for Mobile IPv6 (RFC 48= 66) to guarantee sufficient signaling security. With the absence of a HA, m= obility support in R/O can be provided in the following manner: * The mobile starts the traffic session from any of its currently sup= ported IP addresses. The selected IP address automatically takes the functi= on of the HoA for this session. This has the advantage that conventional tr= ansport is used as long as the mobile does not move, i.e. mobility headers = and CoA-vs-HoA mapping is not needed. The HoA must have been generated via = CGA in compliance with RFC 4866. * The mobile must conduct a "home-test" from this HoA in compliance w= ith RFC 4866. It may conduct the home-test prior to session establishment, = e.g. to find out if the correspondent supports the standard. * All binding update handshakes are conducted on the direct path acco= rding to RFC 4866. * Since sessions are always started from a currently supported IP add= ress, temporally overlapping sessions may use different HoAs. A multi-homed= mobile may also decide to start sessions from different simultaneously sup= ported IP addresses. There is no principle problem here. * Opposed to RFC 4866, the mobile need not perform the CoA registrati= on with the HA. * The mobile must be able to deregister the HoA at the correspondent = in case the HoA is not supported anymore. This ensures that the corresponde= nt does not send packets to the HoA. After deregistration of the HoA, the H= oA is still used by higher protocol layers of ongoing sessions. It must sti= ll be included in the mobility headers for these sessions. * When the mobile has HA support and the HA becomes temporarily unava= ilable, the mobile simply continues R/O without HA as outlined in the prior= points. * The mobile can publish its IP address in any location service. This= allows other hosts to initiate sessions with the mobile. These sessions en= joy route-optimized mobility support only if the published IP address was g= enerated via CGA in compliance with RFC 4866. OPEN ISSUES These extensions have to be made compliant with RFC 5648 (multiple CoA regi= stration), RFC 3963 (NEMO) and others. More discussions are necessary. --_000_154773479ED2314980CB638A48FC44348334CE4FUSNAVSXCHMBSA2n_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:st1=3D"urn:schemas-microsoft-com:office:smarttags" xmlns=3D"http://ww= w.w3.org/TR/REC-html40"> <head> <meta http-equiv=3DContent-Type content=3D"text/html; charset=3Dus-ascii"> <meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)"> <o:SmartTagType namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags" name=3D"City"/> <o:SmartTagType namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags" name=3D"place"/> <!--[if !mso]> <style> st1\:*{behavior:url(#default#ieooui) } </style> <![endif]--> <style> <!-- /* Font Definitions */ @font-face {font-family:Wingdings; panose-1:5 0 0 0 0 0 0 0 0 0;} @font-face {font-family:SimSun; panose-1:2 1 6 0 3 1 1 1 1 1;} @font-face {font-family:"\@SimSun"; panose-1:2 1 6 0 3 1 1 1 1 1;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0pt; margin-bottom:.0001pt; font-size:10.0pt; font-family:"Times New Roman";} a:link, span.MsoHyperlink {color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {color:purple; text-decoration:underline;} span.EmailStyle17 {mso-style-type:personal-compose; font-family:Arial; color:windowtext;} @page Section1 {size:612.0pt 792.0pt; margin:72.0pt 90.0pt 72.0pt 90.0pt;} div.Section1 {page:Section1;} /* List Definitions */ @list l0 {mso-list-id:462961695; mso-list-type:hybrid; mso-list-template-ids:-2116359956 -727278766 67698691 67698693 67698689 67= 698691 67698693 67698689 67698691 67698693;} @list l0:level1 {mso-level-number-format:bullet; mso-level-text:\F0B7; mso-level-tab-stop:-5.0pt; mso-level-number-position:left; margin-left:14.0pt; text-indent:-14.0pt; mso-ansi-font-size:9.0pt; font-family:Symbol;} @list l1 {mso-list-id:823199790; mso-list-type:hybrid; mso-list-template-ids:-198536934 -727278766 67698691 67698693 67698689 676= 98691 67698693 67698689 67698691 67698693;} @list l1:level1 {mso-level-number-format:bullet; mso-level-text:\F0B7; mso-level-tab-stop:-5.0pt; mso-level-number-position:left; margin-left:14.0pt; text-indent:-14.0pt; mso-ansi-font-size:9.0pt; font-family:Symbol;} @list l2 {mso-list-id:2000302011; mso-list-type:hybrid; mso-list-template-ids:-1553676858 -727278766 67698691 67698693 67698689 67= 698691 67698693 67698689 67698691 67698693;} @list l2:level1 {mso-level-number-format:bullet; mso-level-text:\F0B7; mso-level-tab-stop:-5.0pt; mso-level-number-position:left; margin-left:14.0pt; text-indent:-14.0pt; mso-ansi-font-size:9.0pt; font-family:Symbol;} ol {margin-bottom:0pt;} ul {margin-bottom:0pt;} --> </style> <!--[if gte mso 9]><xml> <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext=3D"edit"> <o:idmap v:ext=3D"edit" data=3D"1" /> </o:shapelayout></xml><![endif]--> </head> <body lang=3DEN-US link=3Dblue vlink=3Dpurple> <div class=3DSection1> <p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1= 0.5pt; font-family:Arial'>All,<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1= 0.5pt; font-family:Arial'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1= 0.5pt; font-family:Arial'>We would like to add a proposal to MEXT that permits the mobile to engage into route-optimization in *absence* of a home agent. <o:p= ></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1= 0.5pt; font-family:Arial'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1= 0.5pt; font-family:Arial'>Such a feature adds robustness to route optimization in = case the HA is temporarily unavailable. Under some circumstances, route optimiza= tion *without* HA may be beneficial for performance reasons. Our proposal requir= es “enhanced route optimization for Mobile IPv6” (RFC 4866) as pre= -requisite.<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1= 0.5pt; font-family:Arial'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1= 0.5pt; font-family:Arial'>We would like to obtain some feedback from the MEXT community via this mailing list before we submit the proposal as a draft to= the workgroup. For this purpose, we have enclosed a high-level outline below. T= hanks.<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1= 0.5pt; font-family:Arial'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1= 0.5pt; font-family:Arial'>Regards,<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1= 0.0pt; font-family:Arial'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1= 0.0pt; font-family:Arial'>Georg Hampel<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1= 0.0pt; font-family:Arial'>Networking & Networks Domain<o:p></o:p></span></font= ></p> <p class=3DMsoNormal><st1:City w:st=3D"on"><st1:place w:st=3D"on"><font siz= e=3D2 face=3DArial><span style=3D'font-size:10.0pt;font-family:Arial'>Bell</spa= n></font></st1:place></st1:City><font face=3DArial><span style=3D'font-family:Arial'> Laboratories<o:p></o:p></sp= an></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1= 0.0pt; font-family:Arial'>Alcatel-Lucent<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1= 0.0pt; font-family:Arial'>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1= 0.0pt; font-family:Arial'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1= 0.5pt; font-family:Arial'>Proposal: Support of Route-Optimization in Absence of Ho= me Agent<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1= 0.5pt; font-family:Arial'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1= 0.5pt; font-family:Arial'>ABSTRACT:<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1= 0.5pt; font-family:Arial'>The proposal allows the mobile to engage into route optimization (R/O) in *absence* of a HA. This feature increases robustness = when the HA becomes temporarily unavailable. Under some circumstances, R/O *with= out* HA may be beneficial for performance reasons. This proposal requires “= ;enhanced route optimization for Mobile IPv6” (RFC 4866) as pre-requisite. <o:p= ></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1= 0.5pt; font-family:Arial'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1= 0.5pt; font-family:Arial'>MOTIVATION:<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1= 0.5pt; font-family:Arial'>In route optimization (R/O), traffic packets are directl= y exchanged between hosts without passing the HA. The mobile, however, still = has to interact with the HA. The HA provides (1) location service, (2) a fallba= ck path in case the direct path breaks, (3) a fallback in case the corresponde= nt does not support the protocol and (4) security support for R/O-related signaling (i.e. home test). These functions come at the following cost:<o:p= ></o:p></span></font></p> <p class=3DMsoNormal style=3D'margin-left:14.0pt;text-indent:-14.0pt;mso-li= st:l2 level1 lfo1'><![if !supportLists]><font size=3D1 face=3DSymbol><span style=3D'font-size:9.0pt;font-family:Symbol'><= span style=3D'mso-list:Ignore'>·<font size=3D1 face=3D"Times New Roman"><= span style=3D'font:7.0pt "Times New Roman"'>      = </span></font></span></span></font><![endif]><font size=3D2 face=3DArial><span style=3D'font-size:10.5pt;font-family:Arial'>Ha= ndovers may fail when the link to the HA or the HA itself are down or congested. Mobili= ty is not supported, when the mobile does not have a HA.<o:p></o:p></span></font>= </p> <p class=3DMsoNormal style=3D'margin-left:14.0pt;text-indent:-14.0pt;mso-li= st:l2 level1 lfo1'><![if !supportLists]><font size=3D1 face=3DSymbol><span style=3D'font-size:9.0pt;font-family:Symbol'><= span style=3D'mso-list:Ignore'>·<font size=3D1 face=3D"Times New Roman"><= span style=3D'font:7.0pt "Times New Roman"'>      = </span></font></span></span></font><![endif]><font size=3D2 face=3DArial><span style=3D'font-size:10.5pt;font-family:Arial'>Wh= en the mobile starts a session outside of its home network, it must use a HoA pert= aining to its home network even if it engages into R/O. This requirement adds air-interface overhead due to mobility headers and processing overhead on t= he mobile. This upfront cost incurs even if the mobile does not move during th= e session.<o:p></o:p></span></font></p> <p class=3DMsoNormal style=3D'margin-left:14.0pt;text-indent:-14.0pt;mso-li= st:l2 level1 lfo1'><![if !supportLists]><font size=3D1 face=3DSymbol><span style=3D'font-size:9.0pt;font-family:Symbol'><= span style=3D'mso-list:Ignore'>·<font size=3D1 face=3D"Times New Roman"><= span style=3D'font:7.0pt "Times New Roman"'>      = </span></font></span></span></font><![endif]><font size=3D2 face=3DArial><span style=3D'font-size:10.5pt;font-family:Arial'>Si= gnaling handshakes have to be conducted between mobile and HA at every mobility event.<o:p></o= :p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1= 0.5pt; font-family:Arial'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1= 0.5pt; font-family:Arial'>Currently, the Mobile IPv6 standard family forces the mo= bile to bear these disadvantages in R/O even if the HA functions are not needed.= This specifically applies to scenarios where: <o:p></o:p></span></font></p> <p class=3DMsoNormal style=3D'margin-left:14.0pt;text-indent:-14.0pt;mso-li= st:l0 level1 lfo3'><![if !supportLists]><font size=3D1 face=3DSymbol><span style=3D'font-size:9.0pt;font-family:Symbol'><= span style=3D'mso-list:Ignore'>·<font size=3D1 face=3D"Times New Roman"><= span style=3D'font:7.0pt "Times New Roman"'>      = </span></font></span></span></font><![endif]><font size=3D2 face=3DArial><span style=3D'font-size:10.5pt;font-family:Arial'>Tr= affic is based on mobile-initiated requests to public servers (majority of present mobile internet traffic). The HA’s location service is not needed for such traffic. Location service may also be provided by other means such as Dynamic DNS or on application layer (e.g. SIP registrar).<o:p></o:p></span>= </font></p> <p class=3DMsoNormal style=3D'margin-left:14.0pt;text-indent:-14.0pt;mso-li= st:l0 level1 lfo3'><![if !supportLists]><font size=3D1 face=3DSymbol><span style=3D'font-size:9.0pt;font-family:Symbol'><= span style=3D'mso-list:Ignore'>·<font size=3D1 face=3D"Times New Roman"><= span style=3D'font:7.0pt "Times New Roman"'>      = </span></font></span></span></font><![endif]><font size=3D2 face=3DArial><span style=3D'font-size:10.5pt;font-family:Arial'>Th= e fallback path through the HA has little value when it shares the weakest link with t= he direct path. Since the weakest link is typically the wireless link, this si= tuation applies to all scenarios where only one air interface is available (this is= the typical case rather than the exception).<o:p></o:p></span></font></p> <p class=3DMsoNormal style=3D'margin-left:14.0pt;text-indent:-14.0pt;mso-li= st:l0 level1 lfo3'><![if !supportLists]><font size=3D1 face=3DSymbol><span style=3D'font-size:9.0pt;font-family:Symbol'><= span style=3D'mso-list:Ignore'>·<font size=3D1 face=3D"Times New Roman"><= span style=3D'font:7.0pt "Times New Roman"'>      = </span></font></span></span></font><![endif]><font size=3D2 face=3DArial><span style=3D'font-size:10.5pt;font-family:Arial'>Th= e mobile may know about the correspondent’s Mobile-IPv6 support from prior sessions or through means external to the standard. <o:p></o:p></span></fon= t></p> <p class=3DMsoNormal style=3D'margin-left:14.0pt;text-indent:-14.0pt;mso-li= st:l0 level1 lfo3'><![if !supportLists]><font size=3D1 face=3DSymbol><span style=3D'font-size:9.0pt;font-family:Symbol'><= span style=3D'mso-list:Ignore'>·<font size=3D1 face=3D"Times New Roman"><= span style=3D'font:7.0pt "Times New Roman"'>      = </span></font></span></span></font><![endif]><font size=3D2 face=3DArial><span style=3D'font-size:10.5pt;font-family:Arial'>Th= e mobile applies the CGA-based procedure of RFC 4866, which makes the HA’s security support for R/O unnecessary. This applies to all cases where state= less addressing is permitted. <o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1= 0.5pt; font-family:Arial'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1= 0.5pt; font-family:Arial'>To increase the flexibility and robustness of route-optimized Mobile IPv6, we propose to make the HA an *optional* rather than a *mandatory* feature, i.e. to permit operation without HA. This propo= sal requires some additional extensions to the present standard.<o:p></o:p></sp= an></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1= 0.5pt; font-family:Arial'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1= 0.5pt; font-family:Arial'>HIGH-LEVEL OUTLINE<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1= 0.5pt; font-family:Arial'>The extensions build on Enhanced Route Optimization for Mobile IPv6 (RFC 4866) to guarantee sufficient signaling security. With the absence of a HA, mobility support in R/O can be provided in the following manner:<o:p></o:p></span></font></p> <p class=3DMsoNormal style=3D'margin-left:14.0pt;text-indent:-14.0pt;mso-li= st:l1 level1 lfo2'><![if !supportLists]><font size=3D1 face=3DSymbol><span style=3D'font-size:9.0pt;font-family:Symbol'><= span style=3D'mso-list:Ignore'>·<font size=3D1 face=3D"Times New Roman"><= span style=3D'font:7.0pt "Times New Roman"'>      = </span></font></span></span></font><![endif]><font size=3D2 face=3DArial><span style=3D'font-size:10.5pt;font-family:Arial'>Th= e mobile starts the traffic session from any of its currently supported IP addresses. The selected IP address automatically takes the function of the HoA for this session. This has the advantage that conventional transport is used as long= as the mobile does not move, i.e. mobility headers and CoA-vs-HoA mapping is n= ot needed. The HoA must have been generated via CGA in compliance with RFC 486= 6. <o:p></o:p></span></font></p> <p class=3DMsoNormal style=3D'margin-left:14.0pt;text-indent:-14.0pt;mso-li= st:l1 level1 lfo2'><![if !supportLists]><font size=3D1 face=3DSymbol><span style=3D'font-size:9.0pt;font-family:Symbol'><= span style=3D'mso-list:Ignore'>·<font size=3D1 face=3D"Times New Roman"><= span style=3D'font:7.0pt "Times New Roman"'>      = </span></font></span></span></font><![endif]><font size=3D2 face=3DArial><span style=3D'font-size:10.5pt;font-family:Arial'>Th= e mobile must conduct a “home-test” from this HoA in compliance with RFC 4866. It may conduct the home-test prior to session establishment, e.g. to = find out if the correspondent supports the standard. <o:p></o:p></span></font></= p> <p class=3DMsoNormal style=3D'margin-left:14.0pt;text-indent:-14.0pt;mso-li= st:l1 level1 lfo2'><![if !supportLists]><font size=3D1 face=3DSymbol><span style=3D'font-size:9.0pt;font-family:Symbol'><= span style=3D'mso-list:Ignore'>·<font size=3D1 face=3D"Times New Roman"><= span style=3D'font:7.0pt "Times New Roman"'>      = </span></font></span></span></font><![endif]><font size=3D2 face=3DArial><span style=3D'font-size:10.5pt;font-family:Arial'>Al= l binding update handshakes are conducted on the direct path according to RFC 4866.<o= :p></o:p></span></font></p> <p class=3DMsoNormal style=3D'margin-left:14.0pt;text-indent:-14.0pt;mso-li= st:l1 level1 lfo2'><![if !supportLists]><font size=3D1 face=3DSymbol><span style=3D'font-size:9.0pt;font-family:Symbol'><= span style=3D'mso-list:Ignore'>·<font size=3D1 face=3D"Times New Roman"><= span style=3D'font:7.0pt "Times New Roman"'>      = </span></font></span></span></font><![endif]><font size=3D2 face=3DArial><span style=3D'font-size:10.5pt;font-family:Arial'>Si= nce sessions are always started from a currently supported IP address, temporal= ly overlapping sessions may use different HoAs. A multi-homed mobile may also decide to st= art sessions from different simultaneously supported IP addresses. There is no principle problem here.<o:p></o:p></span></font></p> <p class=3DMsoNormal style=3D'margin-left:14.0pt;text-indent:-14.0pt;mso-li= st:l1 level1 lfo2'><![if !supportLists]><font size=3D1 face=3DSymbol><span style=3D'font-size:9.0pt;font-family:Symbol'><= span style=3D'mso-list:Ignore'>·<font size=3D1 face=3D"Times New Roman"><= span style=3D'font:7.0pt "Times New Roman"'>      = </span></font></span></span></font><![endif]><font size=3D2 face=3DArial><span style=3D'font-size:10.5pt;font-family:Arial'>Op= posed to RFC 4866, the mobile need not perform the CoA registration with the HA.<o:p= ></o:p></span></font></p> <p class=3DMsoNormal style=3D'margin-left:14.0pt;text-indent:-14.0pt;mso-li= st:l1 level1 lfo2'><![if !supportLists]><font size=3D1 face=3DSymbol><span style=3D'font-size:9.0pt;font-family:Symbol'><= span style=3D'mso-list:Ignore'>·<font size=3D1 face=3D"Times New Roman"><= span style=3D'font:7.0pt "Times New Roman"'>      = </span></font></span></span></font><![endif]><font size=3D2 face=3DArial><span style=3D'font-size:10.5pt;font-family:Arial'>Th= e mobile must be able to deregister the HoA at the correspondent in case the HoA is not supported anymore. This ensures that the correspondent does not send packet= s to the HoA. After deregistration of the HoA, the HoA is still used by higher protocol layers of ongoing sessions. It must still be included in the mobil= ity headers for these sessions.<o:p></o:p></span></font></p> <p class=3DMsoNormal style=3D'margin-left:14.0pt;text-indent:-14.0pt;mso-li= st:l1 level1 lfo2'><![if !supportLists]><font size=3D1 face=3DSymbol><span style=3D'font-size:9.0pt;font-family:Symbol'><= span style=3D'mso-list:Ignore'>·<font size=3D1 face=3D"Times New Roman"><= span style=3D'font:7.0pt "Times New Roman"'>      = </span></font></span></span></font><![endif]><font size=3D2 face=3DArial><span style=3D'font-size:10.5pt;font-family:Arial'>Wh= en the mobile has HA support and the HA becomes temporarily unavailable, the mobil= e simply continues R/O without HA as outlined in the prior points.<o:p></o:p>= </span></font></p> <p class=3DMsoNormal style=3D'margin-left:14.0pt;text-indent:-14.0pt;mso-li= st:l1 level1 lfo2'><![if !supportLists]><font size=3D1 face=3DSymbol><span style=3D'font-size:9.0pt;font-family:Symbol'><= span style=3D'mso-list:Ignore'>·<font size=3D1 face=3D"Times New Roman"><= span style=3D'font:7.0pt "Times New Roman"'>      = </span></font></span></span></font><![endif]><font size=3D2 face=3DArial><span style=3D'font-size:10.5pt;font-family:Arial'>Th= e mobile can publish its IP address in any location service. This allows other hosts to = initiate sessions with the mobile. These sessions enjoy route-optimized mobility sup= port only if the published IP address was generated via CGA in compliance with R= FC 4866.<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1= 0.5pt; font-family:Arial'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1= 0.5pt; font-family:Arial'>OPEN ISSUES<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1= 0.5pt; font-family:Arial'>These extensions have to be made compliant with RFC 5648 (multiple CoA registration), RFC 3963 (NEMO) and others. More discussions a= re necessary.<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1= 0.5pt; font-family:Arial'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1= 0.5pt; font-family:Arial'><o:p> </o:p></span></font></p> </div> </body> </html> --_000_154773479ED2314980CB638A48FC44348334CE4FUSNAVSXCHMBSA2n_-- From julienl@qualcomm.com Thu Jan 20 13:24:44 2011 Return-Path: <julienl@qualcomm.com> X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 353923A6831 for <mext@core3.amsl.com>; Thu, 20 Jan 2011 13:24:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.401 X-Spam-Level: X-Spam-Status: No, score=-106.401 tagged_above=-999 required=5 tests=[AWL=0.197, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g+pND+RhBuXg for <mext@core3.amsl.com>; Thu, 20 Jan 2011 13:24:36 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 195943A682C for <mext@ietf.org>; Thu, 20 Jan 2011 13:24:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1295558840; x=1327094840; h=from:to:cc:subject:thread-topic:thread-index:date: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: x-originating-ip:content-type:mime-version; z=From:=20"Laganier,=20Julien"=20<julienl@qualcomm.com> |To:=20"Hampel,=20K=20Georg=20(K=20Georg)"=20<georg.hampe l@alcatel-lucent.com>,=0D=0A=09"mext@ietf.org"=20<mext@ie tf.org>|CC:=20"Klein,=09Thierry=20E=20(Thierry)"=20<thier ry.klein@alcatel-lucent.com>|Subject:=20RE:=20Support=20o f=20route=20optimization=20in=20*absence*=20of=20HA |Thread-Topic:=20Support=20of=20route=20optimization=20in =20*absence*=20of=20HA|Thread-Index:=20Acu43ZmfXvNW17TRRj u54k2cv8RwfQACxVVw|Date:=20Thu,=2020=20Jan=202011=2021:27 :16=20+0000|Message-ID:=20<98A16B2D00B5724F81E80EF1927A02 97036BB6@nasanexd01e.na.qualcomm.com>|References:=20<1547 73479ED2314980CB638A48FC44348334CE4F@USNAVSXCHMBSA2.ndc.a lcatel-lucent.com>|In-Reply-To:=20<154773479ED2314980CB63 8A48FC44348334CE4F@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> |Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|x-originating-ip: =20[172.30.48.1]|Content-Type:=20multipart/alternative=3B =0D=0A=09boundary=3D"_000_98A16B2D00B5724F81E80EF1927A029 7036BB6nasanexd01enaqual_"|MIME-Version:=201.0; bh=EvWI44GvKzcR4yVDHj+HCgfwtU1FLvk9uv1wx+jWeq0=; b=XNTxMThQU0VMKItdo/1wa1AngkUwYx8xG+HSQouL2Zpd60C7bj1Xq1Am 1QKqrocxjthuX38mR5zexl/cvIvzcqBxIfQ1qwX70kZ6dShfExQ4TuayY uALx9ZRm/3nO0vuas/Pi0pLkm2cYhbY3e5sDex9VuCnr23pd27/jSKY15 o=; X-IronPort-AV: E=McAfee;i="5400,1158,6232"; a="71285253" Received: from ironmsg02-r.qualcomm.com ([172.30.46.16]) by wolverine01.qualcomm.com with ESMTP; 20 Jan 2011 13:27:17 -0800 X-IronPort-AV: E=Sophos;i="4.60,351,1291622400"; d="scan'208,217";a="111292564" Received: from nasanexhub04.qualcomm.com (HELO nasanexhub04.na.qualcomm.com) ([129.46.134.222]) by ironmsg02-R.qualcomm.com with ESMTP/TLS/RC4-MD5; 20 Jan 2011 13:27:17 -0800 Received: from nasanexhc09.na.qualcomm.com (172.30.39.8) by nasanexhub04.na.qualcomm.com (129.46.134.222) with Microsoft SMTP Server (TLS) id 8.3.83.0; Thu, 20 Jan 2011 13:27:17 -0800 Received: from NASANEXD01E.na.qualcomm.com ([fe80::6555:8c37:4ee3:efc4]) by nasanexhc09.na.qualcomm.com ([::1]) with mapi id 14.01.0218.012; Thu, 20 Jan 2011 13:27:17 -0800 From: "Laganier, Julien" <julienl@qualcomm.com> To: "Hampel, K Georg (K Georg)" <georg.hampel@alcatel-lucent.com>, "mext@ietf.org" <mext@ietf.org> Thread-Topic: Support of route optimization in *absence* of HA Thread-Index: Acu43ZmfXvNW17TRRju54k2cv8RwfQACxVVw Date: Thu, 20 Jan 2011 21:27:16 +0000 Message-ID: <98A16B2D00B5724F81E80EF1927A0297036BB6@nasanexd01e.na.qualcomm.com> References: <154773479ED2314980CB638A48FC44348334CE4F@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> In-Reply-To: <154773479ED2314980CB638A48FC44348334CE4F@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.30.48.1] Content-Type: multipart/alternative; boundary="_000_98A16B2D00B5724F81E80EF1927A0297036BB6nasanexd01enaqual_" MIME-Version: 1.0 Cc: "Klein, Thierry E \(Thierry\)" <thierry.klein@alcatel-lucent.com> Subject: Re: [MEXT] Support of route optimization in *absence* of HA X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG <mext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/mext> List-Post: <mailto:mext@ietf.org> List-Help: <mailto:mext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 20 Jan 2011 21:24:44 -0000 --_000_98A16B2D00B5724F81E80EF1927A0297036BB6nasanexd01enaqual_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Georg, Is it correct that functionally your proposal is similar to Homeless Mobile= IPv6: http://tools.ietf.org/html/draft-nikander-mobileip-homelessv6-01 Best, --julien From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of Ham= pel, K Georg (K Georg) Sent: Thursday, January 20, 2011 12:07 PM To: mext@ietf.org Cc: Hampel, K Georg (K Georg); Klein, Thierry E (Thierry) Subject: [MEXT] Support of route optimization in *absence* of HA All, We would like to add a proposal to MEXT that permits the mobile to engage i= nto route-optimization in *absence* of a home agent. Such a feature adds robustness to route optimization in case the HA is temp= orarily unavailable. Under some circumstances, route optimization *without*= HA may be beneficial for performance reasons. Our proposal requires "enhan= ced route optimization for Mobile IPv6" (RFC 4866) as pre-requisite. We would like to obtain some feedback from the MEXT community via this mail= ing list before we submit the proposal as a draft to the workgroup. For thi= s purpose, we have enclosed a high-level outline below. Thanks. Regards, Georg Hampel Networking & Networks Domain Bell Laboratories Alcatel-Lucent =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Proposal: Support of Route-Optimization in Absence of Home Agent ABSTRACT: The proposal allows the mobile to engage into route optimization (R/O) in *= absence* of a HA. This feature increases robustness when the HA becomes tem= porarily unavailable. Under some circumstances, R/O *without* HA may be ben= eficial for performance reasons. This proposal requires "enhanced route opt= imization for Mobile IPv6" (RFC 4866) as pre-requisite. MOTIVATION: In route optimization (R/O), traffic packets are directly exchanged between= hosts without passing the HA. The mobile, however, still has to interact w= ith the HA. The HA provides (1) location service, (2) a fallback path in ca= se the direct path breaks, (3) a fallback in case the correspondent does no= t support the protocol and (4) security support for R/O-related signaling (= i.e. home test). These functions come at the following cost: * Handovers may fail when the link to the HA or the HA itself are dow= n or congested. Mobility is not supported, when the mobile does not have a = HA. * When the mobile starts a session outside of its home network, it mu= st use a HoA pertaining to its home network even if it engages into R/O. Th= is requirement adds air-interface overhead due to mobility headers and proc= essing overhead on the mobile. This upfront cost incurs even if the mobile = does not move during the session. * Signaling handshakes have to be conducted between mobile and HA at = every mobility event. Currently, the Mobile IPv6 standard family forces the mobile to bear these = disadvantages in R/O even if the HA functions are not needed. This specific= ally applies to scenarios where: * Traffic is based on mobile-initiated requests to public servers (ma= jority of present mobile internet traffic). The HA's location service is no= t needed for such traffic. Location service may also be provided by other m= eans such as Dynamic DNS or on application layer (e.g. SIP registrar). * The fallback path through the HA has little value when it shares th= e weakest link with the direct path. Since the weakest link is typically th= e wireless link, this situation applies to all scenarios where only one air= interface is available (this is the typical case rather than the exception= ). * The mobile may know about the correspondent's Mobile-IPv6 support f= rom prior sessions or through means external to the standard. * The mobile applies the CGA-based procedure of RFC 4866, which makes= the HA's security support for R/O unnecessary. This applies to all cases w= here stateless addressing is permitted. To increase the flexibility and robustness of route-optimized Mobile IPv6, = we propose to make the HA an *optional* rather than a *mandatory* feature, = i.e. to permit operation without HA. This proposal requires some additional= extensions to the present standard. HIGH-LEVEL OUTLINE The extensions build on Enhanced Route Optimization for Mobile IPv6 (RFC 48= 66) to guarantee sufficient signaling security. With the absence of a HA, m= obility support in R/O can be provided in the following manner: * The mobile starts the traffic session from any of its currently sup= ported IP addresses. The selected IP address automatically takes the functi= on of the HoA for this session. This has the advantage that conventional tr= ansport is used as long as the mobile does not move, i.e. mobility headers = and CoA-vs-HoA mapping is not needed. The HoA must have been generated via = CGA in compliance with RFC 4866. * The mobile must conduct a "home-test" from this HoA in compliance w= ith RFC 4866. It may conduct the home-test prior to session establishment, = e.g. to find out if the correspondent supports the standard. * All binding update handshakes are conducted on the direct path acco= rding to RFC 4866. * Since sessions are always started from a currently supported IP add= ress, temporally overlapping sessions may use different HoAs. A multi-homed= mobile may also decide to start sessions from different simultaneously sup= ported IP addresses. There is no principle problem here. * Opposed to RFC 4866, the mobile need not perform the CoA registrati= on with the HA. * The mobile must be able to deregister the HoA at the correspondent = in case the HoA is not supported anymore. This ensures that the corresponde= nt does not send packets to the HoA. After deregistration of the HoA, the H= oA is still used by higher protocol layers of ongoing sessions. It must sti= ll be included in the mobility headers for these sessions. * When the mobile has HA support and the HA becomes temporarily unava= ilable, the mobile simply continues R/O without HA as outlined in the prior= points. * The mobile can publish its IP address in any location service. This= allows other hosts to initiate sessions with the mobile. These sessions en= joy route-optimized mobility support only if the published IP address was g= enerated via CGA in compliance with RFC 4866. OPEN ISSUES These extensions have to be made compliant with RFC 5648 (multiple CoA regi= stration), RFC 3963 (NEMO) and others. More discussions are necessary. --_000_98A16B2D00B5724F81E80EF1927A0297036BB6nasanexd01enaqual_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:x=3D"urn:schemas-microsoft-com:office:excel" xmlns:p=3D"urn:schemas-m= icrosoft-com:office:powerpoint" xmlns:a=3D"urn:schemas-microsoft-com:office= :access" xmlns:dt=3D"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s=3D"= uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs=3D"urn:schemas-microsof= t-com:rowset" xmlns:z=3D"#RowsetSchema" xmlns:b=3D"urn:schemas-microsoft-co= m:office:publisher" xmlns:ss=3D"urn:schemas-microsoft-com:office:spreadshee= t" xmlns:c=3D"urn:schemas-microsoft-com:office:component:spreadsheet" xmlns= :odc=3D"urn:schemas-microsoft-com:office:odc" xmlns:oa=3D"urn:schemas-micro= soft-com:office:activation" xmlns:html=3D"http://www.w3.org/TR/REC-html40" = xmlns:q=3D"http://schemas.xmlsoap.org/soap/envelope/" xmlns:rtc=3D"http://m= icrosoft.com/officenet/conferencing" xmlns:D=3D"DAV:" xmlns:Repl=3D"http://= schemas.microsoft.com/repl/" xmlns:mt=3D"http://schemas.microsoft.com/share= point/soap/meetings/" xmlns:x2=3D"http://schemas.microsoft.com/office/excel= /2003/xml" xmlns:ppda=3D"http://www.passport.com/NameSpace.xsd" xmlns:ois= =3D"http://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir=3D"http://= schemas.microsoft.com/sharepoint/soap/directory/" xmlns:ds=3D"http://www.w3= .org/2000/09/xmldsig#" xmlns:dsp=3D"http://schemas.microsoft.com/sharepoint= /dsp" xmlns:udc=3D"http://schemas.microsoft.com/data/udc" xmlns:xsd=3D"http= ://www.w3.org/2001/XMLSchema" xmlns:sub=3D"http://schemas.microsoft.com/sha= repoint/soap/2002/1/alerts/" xmlns:ec=3D"http://www.w3.org/2001/04/xmlenc#"= xmlns:sp=3D"http://schemas.microsoft.com/sharepoint/" xmlns:sps=3D"http://= schemas.microsoft.com/sharepoint/soap/" xmlns:xsi=3D"http://www.w3.org/2001= /XMLSchema-instance" xmlns:udcs=3D"http://schemas.microsoft.com/data/udc/so= ap" xmlns:udcxf=3D"http://schemas.microsoft.com/data/udc/xmlfile" xmlns:udc= p2p=3D"http://schemas.microsoft.com/data/udc/parttopart" xmlns:wf=3D"http:/= /schemas.microsoft.com/sharepoint/soap/workflow/" xmlns:dsss=3D"http://sche= mas.microsoft.com/office/2006/digsig-setup" xmlns:dssi=3D"http://schemas.mi= crosoft.com/office/2006/digsig" xmlns:mdssi=3D"http://schemas.openxmlformat= s.org/package/2006/digital-signature" xmlns:mver=3D"http://schemas.openxmlf= ormats.org/markup-compatibility/2006" xmlns:m=3D"http://schemas.microsoft.c= om/office/2004/12/omml" xmlns:mrels=3D"http://schemas.openxmlformats.org/pa= ckage/2006/relationships" xmlns:spwp=3D"http://microsoft.com/sharepoint/web= partpages" xmlns:ex12t=3D"http://schemas.microsoft.com/exchange/services/20= 06/types" xmlns:ex12m=3D"http://schemas.microsoft.com/exchange/services/200= 6/messages" xmlns:pptsl=3D"http://schemas.microsoft.com/sharepoint/soap/Sli= deLibrary/" xmlns:spsl=3D"http://microsoft.com/webservices/SharePointPortal= Server/PublishedLinksService" xmlns:Z=3D"urn:schemas-microsoft-com:" xmlns:= st=3D"" xmlns=3D"http://www.w3.org/TR/REC-html40"> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"= > <meta name=3D"Generator" content=3D"Microsoft Word 12 (filtered medium)"> <style> <!-- /* Font Definitions */ @font-face {font-family:"MS Mincho"; panose-1:2 2 6 9 4 2 5 8 3 4;} @font-face {font-family:"Cambria Math"; panose-1:2 4 5 3 5 4 6 3 2 4;} @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} @font-face {font-family:Tahoma; panose-1:2 11 6 4 3 5 4 4 2 4;} @font-face {font-family:"\@MS Mincho"; panose-1:2 2 6 9 4 2 5 8 3 4;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0in; margin-bottom:.0001pt; font-size:10.0pt; font-family:"Times New Roman","serif";} a:link, span.MsoHyperlink {mso-style-priority:99; color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {mso-style-priority:99; color:purple; text-decoration:underline;} span.EmailStyle17 {mso-style-type:personal; font-family:"Arial","sans-serif"; color:windowtext;} span.EmailStyle18 {mso-style-type:personal-reply; font-family:"Calibri","sans-serif"; color:#1F497D;} .MsoChpDefault {mso-style-type:export-only; font-size:10.0pt;} @page Section1 {size:8.5in 11.0in; margin:1.0in 1.25in 1.0in 1.25in;} div.Section1 {page:Section1;} /* List Definitions */ @list l0 {mso-list-id:462961695; mso-list-type:hybrid; mso-list-template-ids:-2116359956 -727278766 67698691 67698693 67698689 67= 698691 67698693 67698689 67698691 67698693;} @list l0:level1 {mso-level-number-format:bullet; mso-level-text:\F0B7; mso-level-tab-stop:-5.0pt; mso-level-number-position:left; margin-left:14.0pt; text-indent:-14.0pt; mso-ansi-font-size:9.0pt; font-family:Symbol;} @list l0:level2 {mso-level-tab-stop:1.0in; mso-level-number-position:left; text-indent:-.25in;} @list l0:level3 {mso-level-tab-stop:1.5in; mso-level-number-position:left; text-indent:-.25in;} @list l0:level4 {mso-level-tab-stop:2.0in; mso-level-number-position:left; text-indent:-.25in;} @list l0:level5 {mso-level-tab-stop:2.5in; mso-level-number-position:left; text-indent:-.25in;} @list l0:level6 {mso-level-tab-stop:3.0in; mso-level-number-position:left; text-indent:-.25in;} @list l0:level7 {mso-level-tab-stop:3.5in; mso-level-number-position:left; text-indent:-.25in;} @list l0:level8 {mso-level-tab-stop:4.0in; mso-level-number-position:left; text-indent:-.25in;} @list l0:level9 {mso-level-tab-stop:4.5in; mso-level-number-position:left; text-indent:-.25in;} @list l1 {mso-list-id:823199790; mso-list-type:hybrid; mso-list-template-ids:-198536934 -727278766 67698691 67698693 67698689 676= 98691 67698693 67698689 67698691 67698693;} @list l1:level1 {mso-level-number-format:bullet; mso-level-text:\F0B7; mso-level-tab-stop:-5.0pt; mso-level-number-position:left; margin-left:14.0pt; text-indent:-14.0pt; mso-ansi-font-size:9.0pt; font-family:Symbol;} @list l1:level2 {mso-level-tab-stop:1.0in; mso-level-number-position:left; text-indent:-.25in;} @list l1:level3 {mso-level-tab-stop:1.5in; mso-level-number-position:left; text-indent:-.25in;} @list l1:level4 {mso-level-tab-stop:2.0in; mso-level-number-position:left; text-indent:-.25in;} @list l1:level5 {mso-level-tab-stop:2.5in; mso-level-number-position:left; text-indent:-.25in;} @list l1:level6 {mso-level-tab-stop:3.0in; mso-level-number-position:left; text-indent:-.25in;} @list l1:level7 {mso-level-tab-stop:3.5in; mso-level-number-position:left; text-indent:-.25in;} @list l1:level8 {mso-level-tab-stop:4.0in; mso-level-number-position:left; text-indent:-.25in;} @list l1:level9 {mso-level-tab-stop:4.5in; mso-level-number-position:left; text-indent:-.25in;} @list l2 {mso-list-id:2000302011; mso-list-type:hybrid; mso-list-template-ids:-1553676858 -727278766 67698691 67698693 67698689 67= 698691 67698693 67698689 67698691 67698693;} @list l2:level1 {mso-level-number-format:bullet; mso-level-text:\F0B7; mso-level-tab-stop:-5.0pt; mso-level-number-position:left; margin-left:14.0pt; text-indent:-14.0pt; mso-ansi-font-size:9.0pt; font-family:Symbol;} @list l2:level2 {mso-level-tab-stop:1.0in; mso-level-number-position:left; text-indent:-.25in;} @list l2:level3 {mso-level-tab-stop:1.5in; mso-level-number-position:left; text-indent:-.25in;} @list l2:level4 {mso-level-tab-stop:2.0in; mso-level-number-position:left; text-indent:-.25in;} @list l2:level5 {mso-level-tab-stop:2.5in; mso-level-number-position:left; text-indent:-.25in;} @list l2:level6 {mso-level-tab-stop:3.0in; mso-level-number-position:left; text-indent:-.25in;} @list l2:level7 {mso-level-tab-stop:3.5in; mso-level-number-position:left; text-indent:-.25in;} @list l2:level8 {mso-level-tab-stop:4.0in; mso-level-number-position:left; text-indent:-.25in;} @list l2:level9 {mso-level-tab-stop:4.5in; mso-level-number-position:left; text-indent:-.25in;} ol {margin-bottom:0in;} ul {margin-bottom:0in;} --> </style><!--[if gte mso 9]><xml> <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext=3D"edit"> <o:idmap v:ext=3D"edit" data=3D"1" /> </o:shapelayout></xml><![endif]--> </head> <body lang=3D"EN-US" link=3D"blue" vlink=3D"purple"> <div class=3D"Section1"> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif"; color:#1F497D">Georg,<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif"; color:#1F497D"><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif"; color:#1F497D">Is it correct that functionally your proposal is similar to = Homeless Mobile IPv6:<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif"; color:#1F497D"><o:p> </o:p></span></p> <p class=3D"MsoNormal"><a href=3D"http://tools.ietf.org/html/draft-nikander= -mobileip-homelessv6-01">http://tools.ietf.org/html/draft-nikander-mobileip= -homelessv6-01</a><o:p></o:p></p> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif"; color:#1F497D">Best,<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif"; color:#1F497D"><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif"; color:#1F497D">--julien<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif"; color:#1F497D"><o:p> </o:p></span></p> <div style=3D"border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in = 4.0pt"> <div> <div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in = 0in 0in"> <p class=3D"MsoNormal"><b><span style=3D"font-family:"Tahoma",&qu= ot;sans-serif"">From:</span></b><span style=3D"font-family:"Tahom= a","sans-serif""> mext-bounces@ietf.org [mailto:mext-bounces= @ietf.org] <b>On Behalf Of </b>Hampel, K Georg (K Georg)<br> <b>Sent:</b> Thursday, January 20, 2011 12:07 PM<br> <b>To:</b> mext@ietf.org<br> <b>Cc:</b> Hampel, K Georg (K Georg); Klein, Thierry E (Thierry)<br> <b>Subject:</b> [MEXT] Support of route optimization in *absence* of HA<o:p= ></o:p></span></p> </div> </div> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:"Ar= ial","sans-serif"">All,<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:"Ar= ial","sans-serif""><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:"Ar= ial","sans-serif"">We would like to add a proposal to MEXT t= hat permits the mobile to engage into route-optimization in *absence* of a = home agent. <o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:"Ar= ial","sans-serif""><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:"Ar= ial","sans-serif"">Such a feature adds robustness to route o= ptimization in case the HA is temporarily unavailable. Under some circumsta= nces, route optimization *without* HA may be beneficial for performance reasons. Our proposal requires “enhanced route optim= ization for Mobile IPv6” (RFC 4866) as pre-requisite.<o:p></o:p></spa= n></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:"Ar= ial","sans-serif""><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:"Ar= ial","sans-serif"">We would like to obtain some feedback fro= m the MEXT community via this mailing list before we submit the proposal as= a draft to the workgroup. For this purpose, we have enclosed a high-level outline below. Thanks.<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:"Ar= ial","sans-serif""><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:"Ar= ial","sans-serif"">Regards,<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-family:"Arial","s= ans-serif""><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-family:"Arial","s= ans-serif"">Georg Hampel<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-family:"Arial","s= ans-serif"">Networking & Networks Domain<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-family:"Arial","s= ans-serif"">Bell Laboratories<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-family:"Arial","s= ans-serif"">Alcatel-Lucent<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-family:"Arial","s= ans-serif"">=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= <o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-family:"Arial","s= ans-serif""><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:"Ar= ial","sans-serif"">Proposal: Support of Route-Optimization i= n Absence of Home Agent<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:"Ar= ial","sans-serif""><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:"Ar= ial","sans-serif"">ABSTRACT:<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:"Ar= ial","sans-serif"">The proposal allows the mobile to engage = into route optimization (R/O) in *absence* of a HA. This feature increases = robustness when the HA becomes temporarily unavailable. Under some circumstances, R/O *without* HA may be beneficial for performan= ce reasons. This proposal requires “enhanced route optimization for M= obile IPv6” (RFC 4866) as pre-requisite. <o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:"Ar= ial","sans-serif""><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:"Ar= ial","sans-serif"">MOTIVATION:<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:"Ar= ial","sans-serif"">In route optimization (R/O), traffic pack= ets are directly exchanged between hosts without passing the HA. The mobile= , however, still has to interact with the HA. The HA provides (1) location service, (2) a fallback path in case the direct path breaks, = (3) a fallback in case the correspondent does not support the protocol and = (4) security support for R/O-related signaling (i.e. home test). These func= tions come at the following cost:<o:p></o:p></span></p> <p class=3D"MsoNormal" style=3D"margin-left:14.0pt;text-indent:-14.0pt;mso-= list:l2 level1 lfo2"> <![if !supportLists]><span style=3D"font-size:9.0pt;font-family:Symbol"><sp= an style=3D"mso-list:Ignore">·<span style=3D"font:7.0pt "Times = New Roman"">       </span></span></span><![endif]><span style=3D"font-size:10.5pt;font-family:= "Arial","sans-serif"">Handovers may fail when the link = to the HA or the HA itself are down or congested. Mobility is not supported= , when the mobile does not have a HA.<o:p></o:p></span></p> <p class=3D"MsoNormal" style=3D"margin-left:14.0pt;text-indent:-14.0pt;mso-= list:l2 level1 lfo2"> <![if !supportLists]><span style=3D"font-size:9.0pt;font-family:Symbol"><sp= an style=3D"mso-list:Ignore">·<span style=3D"font:7.0pt "Times = New Roman"">       </span></span></span><![endif]><span style=3D"font-size:10.5pt;font-family:= "Arial","sans-serif"">When the mobile starts a session = outside of its home network, it must use a HoA pertaining to its home netwo= rk even if it engages into R/O. This requirement adds air-interface overhead due to mobility headers and processing overhead on = the mobile. This upfront cost incurs even if the mobile does not move durin= g the session.<o:p></o:p></span></p> <p class=3D"MsoNormal" style=3D"margin-left:14.0pt;text-indent:-14.0pt;mso-= list:l2 level1 lfo2"> <![if !supportLists]><span style=3D"font-size:9.0pt;font-family:Symbol"><sp= an style=3D"mso-list:Ignore">·<span style=3D"font:7.0pt "Times = New Roman"">       </span></span></span><![endif]><span style=3D"font-size:10.5pt;font-family:= "Arial","sans-serif"">Signaling handshakes have to be c= onducted between mobile and HA at every mobility event.<o:p></o:p></span></= p> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:"Ar= ial","sans-serif""><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:"Ar= ial","sans-serif"">Currently, the Mobile IPv6 standard famil= y forces the mobile to bear these disadvantages in R/O even if the HA funct= ions are not needed. This specifically applies to scenarios where: <o:p></o:p></span></p> <p class=3D"MsoNormal" style=3D"margin-left:14.0pt;text-indent:-14.0pt;mso-= list:l0 level1 lfo4"> <![if !supportLists]><span style=3D"font-size:9.0pt;font-family:Symbol"><sp= an style=3D"mso-list:Ignore">·<span style=3D"font:7.0pt "Times = New Roman"">       </span></span></span><![endif]><span style=3D"font-size:10.5pt;font-family:= "Arial","sans-serif"">Traffic is based on mobile-initia= ted requests to public servers (majority of present mobile internet traffic= ). The HA’s location service is not needed for such traffic. Location service may also be provided by other means such as Dynamic DNS o= r on application layer (e.g. SIP registrar).<o:p></o:p></span></p> <p class=3D"MsoNormal" style=3D"margin-left:14.0pt;text-indent:-14.0pt;mso-= list:l0 level1 lfo4"> <![if !supportLists]><span style=3D"font-size:9.0pt;font-family:Symbol"><sp= an style=3D"mso-list:Ignore">·<span style=3D"font:7.0pt "Times = New Roman"">       </span></span></span><![endif]><span style=3D"font-size:10.5pt;font-family:= "Arial","sans-serif"">The fallback path through the HA = has little value when it shares the weakest link with the direct path. Sinc= e the weakest link is typically the wireless link, this situation applies to all scenarios where only one air interface is availab= le (this is the typical case rather than the exception).<o:p></o:p></span><= /p> <p class=3D"MsoNormal" style=3D"margin-left:14.0pt;text-indent:-14.0pt;mso-= list:l0 level1 lfo4"> <![if !supportLists]><span style=3D"font-size:9.0pt;font-family:Symbol"><sp= an style=3D"mso-list:Ignore">·<span style=3D"font:7.0pt "Times = New Roman"">       </span></span></span><![endif]><span style=3D"font-size:10.5pt;font-family:= "Arial","sans-serif"">The mobile may know about the cor= respondent’s Mobile-IPv6 support from prior sessions or through means= external to the standard. <o:p></o:p></span></p> <p class=3D"MsoNormal" style=3D"margin-left:14.0pt;text-indent:-14.0pt;mso-= list:l0 level1 lfo4"> <![if !supportLists]><span style=3D"font-size:9.0pt;font-family:Symbol"><sp= an style=3D"mso-list:Ignore">·<span style=3D"font:7.0pt "Times = New Roman"">       </span></span></span><![endif]><span style=3D"font-size:10.5pt;font-family:= "Arial","sans-serif"">The mobile applies the CGA-based = procedure of RFC 4866, which makes the HA’s security support for R/O = unnecessary. This applies to all cases where stateless addressing is permitted. <o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:"Ar= ial","sans-serif""><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:"Ar= ial","sans-serif"">To increase the flexibility and robustnes= s of route-optimized Mobile IPv6, we propose to make the HA an *optional* r= ather than a *mandatory* feature, i.e. to permit operation without HA. This proposal requires some additional extensions to the prese= nt standard.<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:"Ar= ial","sans-serif""><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:"Ar= ial","sans-serif"">HIGH-LEVEL OUTLINE<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:"Ar= ial","sans-serif"">The extensions build on Enhanced Route Op= timization for Mobile IPv6 (RFC 4866) to guarantee sufficient signaling sec= urity. With the absence of a HA, mobility support in R/O can be provided in the following manner:<o:p></o:p></span></p> <p class=3D"MsoNormal" style=3D"margin-left:14.0pt;text-indent:-14.0pt;mso-= list:l1 level1 lfo6"> <![if !supportLists]><span style=3D"font-size:9.0pt;font-family:Symbol"><sp= an style=3D"mso-list:Ignore">·<span style=3D"font:7.0pt "Times = New Roman"">       </span></span></span><![endif]><span style=3D"font-size:10.5pt;font-family:= "Arial","sans-serif"">The mobile starts the traffic ses= sion from any of its currently supported IP addresses. The selected IP addr= ess automatically takes the function of the HoA for this session. This has the advantage that conventional transport is used as lon= g as the mobile does not move, i.e. mobility headers and CoA-vs-HoA mapping= is not needed. The HoA must have been generated via CGA in compliance with= RFC 4866. <o:p></o:p></span></p> <p class=3D"MsoNormal" style=3D"margin-left:14.0pt;text-indent:-14.0pt;mso-= list:l1 level1 lfo6"> <![if !supportLists]><span style=3D"font-size:9.0pt;font-family:Symbol"><sp= an style=3D"mso-list:Ignore">·<span style=3D"font:7.0pt "Times = New Roman"">       </span></span></span><![endif]><span style=3D"font-size:10.5pt;font-family:= "Arial","sans-serif"">The mobile must conduct a “= home-test” from this HoA in compliance with RFC 4866. It may conduct = the home-test prior to session establishment, e.g. to find out if the correspondent supports the standard. <o:p></o:p></span></p> <p class=3D"MsoNormal" style=3D"margin-left:14.0pt;text-indent:-14.0pt;mso-= list:l1 level1 lfo6"> <![if !supportLists]><span style=3D"font-size:9.0pt;font-family:Symbol"><sp= an style=3D"mso-list:Ignore">·<span style=3D"font:7.0pt "Times = New Roman"">       </span></span></span><![endif]><span style=3D"font-size:10.5pt;font-family:= "Arial","sans-serif"">All binding update handshakes are= conducted on the direct path according to RFC 4866.<o:p></o:p></span></p> <p class=3D"MsoNormal" style=3D"margin-left:14.0pt;text-indent:-14.0pt;mso-= list:l1 level1 lfo6"> <![if !supportLists]><span style=3D"font-size:9.0pt;font-family:Symbol"><sp= an style=3D"mso-list:Ignore">·<span style=3D"font:7.0pt "Times = New Roman"">       </span></span></span><![endif]><span style=3D"font-size:10.5pt;font-family:= "Arial","sans-serif"">Since sessions are always started= from a currently supported IP address, temporally overlapping sessions may= use different HoAs. A multi-homed mobile may also decide to start sessions from different simultaneously supported IP addresses. Th= ere is no principle problem here.<o:p></o:p></span></p> <p class=3D"MsoNormal" style=3D"margin-left:14.0pt;text-indent:-14.0pt;mso-= list:l1 level1 lfo6"> <![if !supportLists]><span style=3D"font-size:9.0pt;font-family:Symbol"><sp= an style=3D"mso-list:Ignore">·<span style=3D"font:7.0pt "Times = New Roman"">       </span></span></span><![endif]><span style=3D"font-size:10.5pt;font-family:= "Arial","sans-serif"">Opposed to RFC 4866, the mobile n= eed not perform the CoA registration with the HA.<o:p></o:p></span></p> <p class=3D"MsoNormal" style=3D"margin-left:14.0pt;text-indent:-14.0pt;mso-= list:l1 level1 lfo6"> <![if !supportLists]><span style=3D"font-size:9.0pt;font-family:Symbol"><sp= an style=3D"mso-list:Ignore">·<span style=3D"font:7.0pt "Times = New Roman"">       </span></span></span><![endif]><span style=3D"font-size:10.5pt;font-family:= "Arial","sans-serif"">The mobile must be able to deregi= ster the HoA at the correspondent in case the HoA is not supported anymore.= This ensures that the correspondent does not send packets to the HoA. After deregistration of the HoA, the HoA is still used by high= er protocol layers of ongoing sessions. It must still be included in the mo= bility headers for these sessions.<o:p></o:p></span></p> <p class=3D"MsoNormal" style=3D"margin-left:14.0pt;text-indent:-14.0pt;mso-= list:l1 level1 lfo6"> <![if !supportLists]><span style=3D"font-size:9.0pt;font-family:Symbol"><sp= an style=3D"mso-list:Ignore">·<span style=3D"font:7.0pt "Times = New Roman"">       </span></span></span><![endif]><span style=3D"font-size:10.5pt;font-family:= "Arial","sans-serif"">When the mobile has HA support an= d the HA becomes temporarily unavailable, the mobile simply continues R/O w= ithout HA as outlined in the prior points.<o:p></o:p></span></p> <p class=3D"MsoNormal" style=3D"margin-left:14.0pt;text-indent:-14.0pt;mso-= list:l1 level1 lfo6"> <![if !supportLists]><span style=3D"font-size:9.0pt;font-family:Symbol"><sp= an style=3D"mso-list:Ignore">·<span style=3D"font:7.0pt "Times = New Roman"">       </span></span></span><![endif]><span style=3D"font-size:10.5pt;font-family:= "Arial","sans-serif"">The mobile can publish its IP add= ress in any location service. This allows other hosts to initiate sessions = with the mobile. These sessions enjoy route-optimized mobility support only if the published IP address was generated via CGA in= compliance with RFC 4866.<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:"Ar= ial","sans-serif""><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:"Ar= ial","sans-serif"">OPEN ISSUES<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:"Ar= ial","sans-serif"">These extensions have to be made complian= t with RFC 5648 (multiple CoA registration), RFC 3963 (NEMO) and others. Mo= re discussions are necessary.<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:"Ar= ial","sans-serif""><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:"Ar= ial","sans-serif""><o:p> </o:p></span></p> </div> </div> </body> </html> --_000_98A16B2D00B5724F81E80EF1927A0297036BB6nasanexd01enaqual_-- From Basavaraj.Patil@nokia.com Thu Jan 20 13:54:07 2011 Return-Path: <Basavaraj.Patil@nokia.com> X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E1C213A6839 for <mext@core3.amsl.com>; Thu, 20 Jan 2011 13:54:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.662 X-Spam-Level: X-Spam-Status: No, score=-103.662 tagged_above=-999 required=5 tests=[AWL=-1.062, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cNlTIFjQKpfW for <mext@core3.amsl.com>; Thu, 20 Jan 2011 13:54:06 -0800 (PST) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by core3.amsl.com (Postfix) with ESMTP id 410C23A682F for <mext@ietf.org>; Thu, 20 Jan 2011 13:54:06 -0800 (PST) Received: from vaebh102.NOE.Nokia.com (vaebh102.europe.nokia.com [10.160.244.23]) by mgw-da02.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p0KLuhBu026552; Thu, 20 Jan 2011 23:56:46 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 20 Jan 2011 23:56:04 +0200 Received: from 008-AM1MMR1-006.mgdnok.nokia.com (65.54.30.61) by NOK-AM1MHUB-04.mgdnok.nokia.com (65.54.30.8) with Microsoft SMTP Server (TLS) id 8.2.255.0; Thu, 20 Jan 2011 22:56:04 +0100 Received: from 008-AM1MPN1-005.mgdnok.nokia.com ([169.254.4.169]) by 008-AM1MMR1-006.mgdnok.nokia.com ([65.54.30.61]) with mapi; Thu, 20 Jan 2011 22:55:56 +0100 From: <Basavaraj.Patil@nokia.com> To: <jan@go6.si>, <mext@ietf.org> Thread-Topic: [MEXT] Review of I-D draft-korhonen-mext-mip6-altsec-06 Thread-Index: AQHLuH0JE4MPNYPORU+/IPQRfHjdipPZ804A Date: Thu, 20 Jan 2011 21:55:56 +0000 Message-ID: <C95E0B38.CD87%basavaraj.patil@nokia.com> In-Reply-To: <4D37F38A.4080602@go6.si> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.101115 Content-Type: text/plain; charset="us-ascii" Content-ID: <deba43fd-163b-490c-aedf-520f02fd7218> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 20 Jan 2011 21:56:04.0547 (UTC) FILETIME=[D597A930:01CBB8EC] X-Nokia-AV: Clean Subject: Re: [MEXT] Review of I-D draft-korhonen-mext-mip6-altsec-06 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG <mext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/mext> List-Post: <mailto:mext@ietf.org> List-Help: <mailto:mext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 20 Jan 2011 21:54:08 -0000 Thanks for the review. Support for route-optimization with the proposed security solution in this I-D is possible. We will describe this in more details in the next rev while also addressing some of your other comments.. -Raj On 1/20/11 2:34 AM, "ext Jan Zorz @ go6.si" <jan@go6.si> wrote: >Hi, > >It took me quite long to write this review, but finally, here it is :) > >Review comments: > >In general the proposal of using an alternative to IPsec and IKEv2 >seems quite okay. The main purpose of Mobile IPv6 is to enable >mobility at the IP layer and hence using TLS which is much more widely >implemented and deployed for use to secure the signaling is good. > >More specific comments: > >- The proposal introduces a new element called HAC. In terms of > deployments such a network element may become central for > bootstrapping Mobile IPv6. The I-D states that the HAC could be > co-located with the HA. In reality, the HAC should be a standalone > entity which interacts with AAA and policy engines in a network. > >- TLS is widely used for security in the Internet today. Hence the use > of TLS does not weaken mobile IPv6 security. TLS is also used only > for bootstrapping and not for securing the signaling or traffic. > >- Describe the steps in figure 1. > >- The security association scope says that it describes whether the SA > is only for signaling or for data as well. Would be useful to make > it more explicit. > >- Route optimization is an important feature of Mobile IPv6. Hence > this alternate security solution should explain how the route > optimization signaling messages are secured. > >- Unclear why HTTP headers (Sec 8.2) are being reserved. Could not > really understand the purpose. > >- Message details are fairly complete and hence should be > implementable. > >In summary, the draft is well written and complete and should be >considered for standardization. > >I'm using DSMIP6-TLS implementations on N900 phone and Ubuntu Linux >laptop in everyday life and it seems to work quite well. There are still >some implementation issues that needs to be fixed, but overall feeling >is very satisfactory. > >Regards, Jan Zorz >go6.si >_______________________________________________ >MEXT mailing list >MEXT@ietf.org >https://www.ietf.org/mailman/listinfo/mext From georg.hampel@alcatel-lucent.com Thu Jan 20 17:22:11 2011 Return-Path: <georg.hampel@alcatel-lucent.com> X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 15F653A6858 for <mext@core3.amsl.com>; Thu, 20 Jan 2011 17:22:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7UBaXeKOE+Bo for <mext@core3.amsl.com>; Thu, 20 Jan 2011 17:22:00 -0800 (PST) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by core3.amsl.com (Postfix) with ESMTP id 23D5C3A680E for <mext@ietf.org>; Thu, 20 Jan 2011 17:21:59 -0800 (PST) Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id p0L1Ohdg021207 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 20 Jan 2011 19:24:43 -0600 (CST) Received: from USNAVSXCHHUB02.ndc.alcatel-lucent.com (usnavsxchhub02.ndc.alcatel-lucent.com [135.3.39.111]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p0L1Ohsg013311 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 20 Jan 2011 19:24:43 -0600 Received: from USNAVSXCHMBSA2.ndc.alcatel-lucent.com ([135.3.39.127]) by USNAVSXCHHUB02.ndc.alcatel-lucent.com ([135.3.39.111]) with mapi; Thu, 20 Jan 2011 19:24:43 -0600 From: "Hampel, K Georg (K Georg)" <georg.hampel@alcatel-lucent.com> To: "Laganier, Julien" <julienl@qualcomm.com>, "mext@ietf.org" <mext@ietf.org> Date: Thu, 20 Jan 2011 19:24:40 -0600 Thread-Topic: Support of route optimization in *absence* of HA Thread-Index: Acu43ZmfXvNW17TRRju54k2cv8RwfQACxVVwAAgzMeA= Message-ID: <154773479ED2314980CB638A48FC44348334CFA1@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> References: <154773479ED2314980CB638A48FC44348334CE4F@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <98A16B2D00B5724F81E80EF1927A0297036BB6@nasanexd01e.na.qualcomm.com> In-Reply-To: <98A16B2D00B5724F81E80EF1927A0297036BB6@nasanexd01e.na.qualcomm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_154773479ED2314980CB638A48FC44348334CFA1USNAVSXCHMBSA2n_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.9 Cc: "Klein, Thierry E \(Thierry\)" <thierry.klein@alcatel-lucent.com> Subject: Re: [MEXT] Support of route optimization in *absence* of HA X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG <mext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/mext> List-Post: <mailto:mext@ietf.org> List-Help: <mailto:mext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 21 Jan 2011 01:22:11 -0000 --_000_154773479ED2314980CB638A48FC44348334CFA1USNAVSXCHMBSA2n_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Julien, The intentions of Homeless MIPv6 are similar to those of our proposal. In contrast to Homeless MIPv6, our proposal requires only minimal upgrades = to the present standard and implementation. (Homeless MIPv6 requires change= s to the TCP/UDP and requires AH, for instance). Here's the core idea of HA-free R/O: 1) When starting a session, the MN self-declares its current IP addre= ss as the "HoA" for this session. This automatically means that it resides = in its "home network" and can conduct the home test directly with CN, i.e. = no home registration required. 2) All further BU/BA signaling is done directly with CN according to = RFC 4866. 3) All further signaling with HA is simply omitted. Our proposal builds on "enhanced route optimization" (RFC 4866), which prov= ides a nice security solution for R/O and creates the ground for HA-free op= eration. Little changes are required: e.g. MN must be able to deregister its HoA at = CN, etc. Regards, Georg ________________________________ From: Laganier, Julien [mailto:julienl@qualcomm.com] Sent: Thursday, January 20, 2011 4:27 PM To: Hampel, K Georg (K Georg); mext@ietf.org Cc: Klein, Thierry E (Thierry) Subject: RE: Support of route optimization in *absence* of HA Georg, Is it correct that functionally your proposal is similar to Homeless Mobile= IPv6: http://tools.ietf.org/html/draft-nikander-mobileip-homelessv6-01 Best, --julien From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of Ham= pel, K Georg (K Georg) Sent: Thursday, January 20, 2011 12:07 PM To: mext@ietf.org Cc: Hampel, K Georg (K Georg); Klein, Thierry E (Thierry) Subject: [MEXT] Support of route optimization in *absence* of HA All, We would like to add a proposal to MEXT that permits the mobile to engage i= nto route-optimization in *absence* of a home agent. Such a feature adds robustness to route optimization in case the HA is temp= orarily unavailable. Under some circumstances, route optimization *without*= HA may be beneficial for performance reasons. Our proposal requires "enhan= ced route optimization for Mobile IPv6" (RFC 4866) as pre-requisite. We would like to obtain some feedback from the MEXT community via this mail= ing list before we submit the proposal as a draft to the workgroup. For thi= s purpose, we have enclosed a high-level outline below. Thanks. Regards, Georg Hampel Networking & Networks Domain Bell Laboratories Alcatel-Lucent =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Proposal: Support of Route-Optimization in Absence of Home Agent ABSTRACT: The proposal allows the mobile to engage into route optimization (R/O) in *= absence* of a HA. This feature increases robustness when the HA becomes tem= porarily unavailable. Under some circumstances, R/O *without* HA may be ben= eficial for performance reasons. This proposal requires "enhanced route opt= imization for Mobile IPv6" (RFC 4866) as pre-requisite. MOTIVATION: In route optimization (R/O), traffic packets are directly exchanged between= hosts without passing the HA. The mobile, however, still has to interact w= ith the HA. The HA provides (1) location service, (2) a fallback path in ca= se the direct path breaks, (3) a fallback in case the correspondent does no= t support the protocol and (4) security support for R/O-related signaling (= i.e. home test). These functions come at the following cost: * Handovers may fail when the link to the HA or the HA itself are dow= n or congested. Mobility is not supported, when the mobile does not have a = HA. * When the mobile starts a session outside of its home network, it mu= st use a HoA pertaining to its home network even if it engages into R/O. Th= is requirement adds air-interface overhead due to mobility headers and proc= essing overhead on the mobile. This upfront cost incurs even if the mobile = does not move during the session. * Signaling handshakes have to be conducted between mobile and HA at = every mobility event. Currently, the Mobile IPv6 standard family forces the mobile to bear these = disadvantages in R/O even if the HA functions are not needed. This specific= ally applies to scenarios where: * Traffic is based on mobile-initiated requests to public servers (ma= jority of present mobile internet traffic). The HA's location service is no= t needed for such traffic. Location service may also be provided by other m= eans such as Dynamic DNS or on application layer (e.g. SIP registrar). * The fallback path through the HA has little value when it shares th= e weakest link with the direct path. Since the weakest link is typically th= e wireless link, this situation applies to all scenarios where only one air= interface is available (this is the typical case rather than the exception= ). * The mobile may know about the correspondent's Mobile-IPv6 support f= rom prior sessions or through means external to the standard. * The mobile applies the CGA-based procedure of RFC 4866, which makes= the HA's security support for R/O unnecessary. This applies to all cases w= here stateless addressing is permitted. To increase the flexibility and robustness of route-optimized Mobile IPv6, = we propose to make the HA an *optional* rather than a *mandatory* feature, = i.e. to permit operation without HA. This proposal requires some additional= extensions to the present standard. HIGH-LEVEL OUTLINE The extensions build on Enhanced Route Optimization for Mobile IPv6 (RFC 48= 66) to guarantee sufficient signaling security. With the absence of a HA, m= obility support in R/O can be provided in the following manner: * The mobile starts the traffic session from any of its currently sup= ported IP addresses. The selected IP address automatically takes the functi= on of the HoA for this session. This has the advantage that conventional tr= ansport is used as long as the mobile does not move, i.e. mobility headers = and CoA-vs-HoA mapping is not needed. The HoA must have been generated via = CGA in compliance with RFC 4866. * The mobile must conduct a "home-test" from this HoA in compliance w= ith RFC 4866. It may conduct the home-test prior to session establishment, = e.g. to find out if the correspondent supports the standard. * All binding update handshakes are conducted on the direct path acco= rding to RFC 4866. * Since sessions are always started from a currently supported IP add= ress, temporally overlapping sessions may use different HoAs. A multi-homed= mobile may also decide to start sessions from different simultaneously sup= ported IP addresses. There is no principle problem here. * Opposed to RFC 4866, the mobile need not perform the CoA registrati= on with the HA. * The mobile must be able to deregister the HoA at the correspondent = in case the HoA is not supported anymore. This ensures that the corresponde= nt does not send packets to the HoA. After deregistration of the HoA, the H= oA is still used by higher protocol layers of ongoing sessions. It must sti= ll be included in the mobility headers for these sessions. * When the mobile has HA support and the HA becomes temporarily unava= ilable, the mobile simply continues R/O without HA as outlined in the prior= points. * The mobile can publish its IP address in any location service. This= allows other hosts to initiate sessions with the mobile. These sessions en= joy route-optimized mobility support only if the published IP address was g= enerated via CGA in compliance with RFC 4866. OPEN ISSUES These extensions have to be made compliant with RFC 5648 (multiple CoA regi= stration), RFC 3963 (NEMO) and others. More discussions are necessary. --_000_154773479ED2314980CB638A48FC44348334CFA1USNAVSXCHMBSA2n_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:x=3D"urn:schemas-microsoft-com:office:excel" xmlns:p=3D"urn:schemas-m= icrosoft-com:office:powerpoint" xmlns:a=3D"urn:schemas-microsoft-com:office= :access" xmlns:dt=3D"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s=3D"= uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs=3D"urn:schemas-microsof= t-com:rowset" xmlns:z=3D"#RowsetSchema" xmlns:b=3D"urn:schemas-microsoft-co= m:office:publisher" xmlns:ss=3D"urn:schemas-microsoft-com:office:spreadshee= t" xmlns:c=3D"urn:schemas-microsoft-com:office:component:spreadsheet" xmlns= :odc=3D"urn:schemas-microsoft-com:office:odc" xmlns:oa=3D"urn:schemas-micro= soft-com:office:activation" xmlns:html=3D"http://www.w3.org/TR/REC-html40" = xmlns:q=3D"http://schemas.xmlsoap.org/soap/envelope/" xmlns:rtc=3D"http://m= icrosoft.com/officenet/conferencing" xmlns:D=3D"DAV:" xmlns:Repl=3D"http://= schemas.microsoft.com/repl/" xmlns:mt=3D"http://schemas.microsoft.com/share= point/soap/meetings/" xmlns:x2=3D"http://schemas.microsoft.com/office/excel= /2003/xml" xmlns:ppda=3D"http://www.passport.com/NameSpace.xsd" xmlns:ois= =3D"http://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir=3D"http://= schemas.microsoft.com/sharepoint/soap/directory/" xmlns:ds=3D"http://www.w3= .org/2000/09/xmldsig#" xmlns:dsp=3D"http://schemas.microsoft.com/sharepoint= /dsp" xmlns:udc=3D"http://schemas.microsoft.com/data/udc" xmlns:xsd=3D"http= ://www.w3.org/2001/XMLSchema" xmlns:sub=3D"http://schemas.microsoft.com/sha= repoint/soap/2002/1/alerts/" xmlns:ec=3D"http://www.w3.org/2001/04/xmlenc#"= xmlns:sp=3D"http://schemas.microsoft.com/sharepoint/" xmlns:sps=3D"http://= schemas.microsoft.com/sharepoint/soap/" xmlns:xsi=3D"http://www.w3.org/2001= /XMLSchema-instance" xmlns:udcs=3D"http://schemas.microsoft.com/data/udc/so= ap" xmlns:udcxf=3D"http://schemas.microsoft.com/data/udc/xmlfile" xmlns:udc= p2p=3D"http://schemas.microsoft.com/data/udc/parttopart" xmlns:st=3D"" = xmlns:st1=3D"urn:schemas-microsoft-com:office:smarttags" xmlns=3D"http://ww= w.w3.org/TR/REC-html40" xmlns:ns2=3D"http://schemas.microsoft.com/sharepoint/soap/workflow/" xmlns:ns3=3D"http://schemas.microsoft.com/office/2006/digsig-setup" xmlns:ns4=3D"http://schemas.microsoft.com/office/2006/digsig" xmlns:ns5=3D"http://schemas.openxmlformats.org/package/2006/digital-signatu= re" xmlns:ns6=3D"http://schemas.openxmlformats.org/markup-compatibility/2006" xmlns:ns1=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns:ns7=3D"http://schemas.openxmlformats.org/package/2006/relationships" xmlns:ns8=3D"http://microsoft.com/sharepoint/webpartpages" xmlns:ns9=3D"http://schemas.microsoft.com/exchange/services/2006/types" xmlns:ns10=3D"http://schemas.microsoft.com/exchange/services/2006/messages" xmlns:ns11=3D"http://schemas.microsoft.com/sharepoint/soap/SlideLibrary/" xmlns:ns12=3D"http://microsoft.com/webservices/SharePointPortalServer/Publi= shedLinksService" xmlns:ns13=3D"urn:schemas-microsoft-com:"> <head> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; charset=3Dus-ascii"= > <meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)"> <!--[if !mso]> <style> v\:* {behavior:url(#default#VML);} o\:* {behavior:url(#default#VML);} w\:* {behavior:url(#default#VML);} .shape {behavior:url(#default#VML);} </style> <![endif]--><o:SmartTagType namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags" name=3D"City"/= > <o:SmartTagType namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags" name=3D"place"/> <!--[if !mso]> <style> st1\:*{behavior:url(#default#ieooui) } </style> <![endif]--> <style> <!--a:link {mso-style-priority:99;} span.MSOHYPERLINK {mso-style-priority:99;} a:visited {mso-style-priority:99;} span.MSOHYPERLINKFOLLOWED {mso-style-priority:99;} /* Font Definitions */ @font-face {font-family:SimSun; panose-1:2 1 6 0 3 1 1 1 1 1;} @font-face {font-family:Tahoma; panose-1:2 11 6 4 3 5 4 4 2 4;} @font-face {font-family:"\@SimSun"; panose-1:2 1 6 0 3 1 1 1 1 1;} @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0pt; margin-bottom:.0001pt; font-size:10.0pt; font-family:"Times New Roman";} a:link, span.MsoHyperlink {color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {color:purple; text-decoration:underline;} span.EmailStyle17 {mso-style-type:personal; font-family:Arial; color:windowtext;} span.EmailStyle18 {mso-style-type:personal; font-family:Calibri; color:#1F497D;} span.EmailStyle19 {mso-style-type:personal-reply; font-family:Arial; color:navy;} @page Section1 {size:612.0pt 792.0pt; margin:72.0pt 90.0pt 72.0pt 90.0pt;} div.Section1 {page:Section1;} /* List Definitions */ @list l0 {mso-list-id:462961695; mso-list-type:hybrid; mso-list-template-ids:-2116359956 -727278766 67698691 67698693 67698689 67= 698691 67698693 67698689 67698691 67698693;} @list l0:level1 {mso-level-number-format:bullet; mso-level-text:\F0B7; mso-level-tab-stop:-5.0pt; mso-level-number-position:left; margin-left:14.0pt; text-indent:-14.0pt; mso-ansi-font-size:9.0pt; font-family:Symbol;} @list l0:level2 {mso-level-tab-stop:72.0pt; mso-level-number-position:left; text-indent:-18.0pt;} @list l0:level3 {mso-level-tab-stop:108.0pt; mso-level-number-position:left; text-indent:-18.0pt;} @list l0:level4 {mso-level-tab-stop:144.0pt; mso-level-number-position:left; text-indent:-18.0pt;} @list l0:level5 {mso-level-tab-stop:180.0pt; mso-level-number-position:left; text-indent:-18.0pt;} @list l0:level6 {mso-level-tab-stop:216.0pt; mso-level-number-position:left; text-indent:-18.0pt;} @list l0:level7 {mso-level-tab-stop:252.0pt; mso-level-number-position:left; text-indent:-18.0pt;} @list l0:level8 {mso-level-tab-stop:288.0pt; mso-level-number-position:left; text-indent:-18.0pt;} @list l0:level9 {mso-level-tab-stop:324.0pt; mso-level-number-position:left; text-indent:-18.0pt;} @list l1 {mso-list-id:823199790; mso-list-type:hybrid; mso-list-template-ids:-198536934 -727278766 67698691 67698693 67698689 676= 98691 67698693 67698689 67698691 67698693;} @list l1:level1 {mso-level-number-format:bullet; mso-level-text:\F0B7; mso-level-tab-stop:-5.0pt; mso-level-number-position:left; margin-left:14.0pt; text-indent:-14.0pt; mso-ansi-font-size:9.0pt; font-family:Symbol;} @list l1:level2 {mso-level-tab-stop:72.0pt; mso-level-number-position:left; text-indent:-18.0pt;} @list l1:level3 {mso-level-tab-stop:108.0pt; mso-level-number-position:left; text-indent:-18.0pt;} @list l1:level4 {mso-level-tab-stop:144.0pt; mso-level-number-position:left; text-indent:-18.0pt;} @list l1:level5 {mso-level-tab-stop:180.0pt; mso-level-number-position:left; text-indent:-18.0pt;} @list l1:level6 {mso-level-tab-stop:216.0pt; mso-level-number-position:left; text-indent:-18.0pt;} @list l1:level7 {mso-level-tab-stop:252.0pt; mso-level-number-position:left; text-indent:-18.0pt;} @list l1:level8 {mso-level-tab-stop:288.0pt; mso-level-number-position:left; text-indent:-18.0pt;} @list l1:level9 {mso-level-tab-stop:324.0pt; mso-level-number-position:left; text-indent:-18.0pt;} @list l2 {mso-list-id:1836452376; mso-list-type:hybrid; mso-list-template-ids:-1378300656 -1558151418 67698713 67698715 67698703 6= 7698713 67698715 67698703 67698713 67698715;} @list l2:level1 {mso-level-text:"%1\)"; mso-level-tab-stop:36.0pt; mso-level-number-position:left; text-indent:-18.0pt;} @list l3 {mso-list-id:2000302011; mso-list-type:hybrid; mso-list-template-ids:-1553676858 -727278766 67698691 67698693 67698689 67= 698691 67698693 67698689 67698691 67698693;} @list l3:level1 {mso-level-number-format:bullet; mso-level-text:\F0B7; mso-level-tab-stop:-5.0pt; mso-level-number-position:left; margin-left:14.0pt; text-indent:-14.0pt; mso-ansi-font-size:9.0pt; font-family:Symbol;} @list l3:level2 {mso-level-tab-stop:72.0pt; mso-level-number-position:left; text-indent:-18.0pt;} @list l3:level3 {mso-level-tab-stop:108.0pt; mso-level-number-position:left; text-indent:-18.0pt;} @list l3:level4 {mso-level-tab-stop:144.0pt; mso-level-number-position:left; text-indent:-18.0pt;} @list l3:level5 {mso-level-tab-stop:180.0pt; mso-level-number-position:left; text-indent:-18.0pt;} @list l3:level6 {mso-level-tab-stop:216.0pt; mso-level-number-position:left; text-indent:-18.0pt;} @list l3:level7 {mso-level-tab-stop:252.0pt; mso-level-number-position:left; text-indent:-18.0pt;} @list l3:level8 {mso-level-tab-stop:288.0pt; mso-level-number-position:left; text-indent:-18.0pt;} @list l3:level9 {mso-level-tab-stop:324.0pt; mso-level-number-position:left; text-indent:-18.0pt;} ol {margin-bottom:0pt;} ul {margin-bottom:0pt;} --> </style> <!--[if gte mso 9]><xml> <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext=3D"edit"> <o:idmap v:ext=3D"edit" data=3D"1" /> </o:shapelayout></xml><![endif]--> </head> <body lang=3DEN-US link=3Dblue vlink=3Dpurple> <div class=3DSection1> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span lang=3D= EN style=3D'font-size:10.0pt;font-family:Arial;color:navy'>Julien,<o:p></o:p><= /span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span lang=3D= EN style=3D'font-size:10.0pt;font-family:Arial;color:navy'><o:p> </o:p></= span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span lang=3D= EN style=3D'font-size:10.0pt;font-family:Arial;color:navy'>The intentions of H= omeless MIPv6 are similar to those of our proposal. <o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span lang=3D= EN style=3D'font-size:10.0pt;font-family:Arial;color:navy'><o:p> </o:p></= span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span lang=3D= EN style=3D'font-size:10.0pt;font-family:Arial;color:navy'>In contrast to Home= less MIPv6, our proposal requires only minimal upgrades to the present standard = and implementation. (Homeless MIPv6 requires changes to the TCP/UDP and require= s AH, for instance).<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span lang=3D= EN style=3D'font-size:10.0pt;font-family:Arial;color:navy'><o:p> </o:p></= span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span lang=3D= EN style=3D'font-size:10.0pt;font-family:Arial;color:navy'>Here’s the co= re idea of HA-free R/O: <o:p></o:p></span></font></p> <p class=3DMsoNormal style=3D'margin-left:36.0pt;text-indent:-18.0pt;mso-li= st:l2 level1 lfo7'><![if !supportLists]><font size=3D2 color=3Dnavy face=3DArial><span lang=3DEN style=3D'font-size:10.0p= t;font-family: Arial;color:navy'><span style=3D'mso-list:Ignore'>1)<font size=3D1 face=3D"Times New Roman"><span style=3D'font:7.0pt "Times New Roman"'> = ;      </span></font></span></span></font><![endif]><font color=3Dnavy face=3DAria= l><span lang=3DEN style=3D'font-family:Arial;color:navy'>When starting a session, t= he MN self-declares its current IP address as the “HoA” for this session. This auto= matically means that it resides in its “home network” and can conduct the home test = directly with CN, i.e. no home registration required.<o:p></o:p></span></font></p> <p class=3DMsoNormal style=3D'margin-left:36.0pt;text-indent:-18.0pt;mso-li= st:l2 level1 lfo7'><![if !supportLists]><font size=3D2 color=3Dnavy face=3DArial><span lang=3DEN style=3D'font-size:10.0p= t;font-family: Arial;color:navy'><span style=3D'mso-list:Ignore'>2)<font size=3D1 face=3D"Times New Roman"><span style=3D'font:7.0pt "Times New Roman"'> = ;      </span></font></span></span></font><![endif]><font color=3Dnavy face=3DAria= l><span lang=3DEN style=3D'font-family:Arial;color:navy'>All further BU/BA signalin= g is done directly with CN according to RFC 4866.<o:p></o:p></span></font></p> <p class=3DMsoNormal style=3D'margin-left:36.0pt;text-indent:-18.0pt;mso-li= st:l2 level1 lfo7'><![if !supportLists]><font size=3D2 color=3Dnavy face=3DArial><span lang=3DEN style=3D'font-size:10.0p= t;font-family: Arial;color:navy'><span style=3D'mso-list:Ignore'>3)<font size=3D1 face=3D"Times New Roman"><span style=3D'font:7.0pt "Times New Roman"'> = ;      </span></font></span></span></font><![endif]><font color=3Dnavy face=3DAria= l><span lang=3DEN style=3D'font-family:Arial;color:navy'>All further signaling with= HA is simply omitted.<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span lang=3D= EN style=3D'font-size:10.0pt;font-family:Arial;color:navy'><o:p> </o:p></= span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span lang=3D= EN style=3D'font-size:10.0pt;font-family:Arial;color:navy'>Our proposal builds= on “enhanced route optimization” (RFC 4866), which provides a nice= security solution for R/O and creates the ground for HA-free operation.<o:p></o:p></= span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span lang=3D= EN style=3D'font-size:10.0pt;font-family:Arial;color:navy'>Little changes are required: e.g. MN must be able to deregister its HoA at CN, etc.<o:p></o:p>= </span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span lang=3D= EN style=3D'font-size:10.0pt;font-family:Arial;color:navy'><o:p> </o:p></= span></font></p> <div> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span lang=3D= EN style=3D'font-size:10.0pt;font-family:Arial;color:navy'>Regards,<o:p></o:p>= </span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span lang=3D= EN style=3D'font-size:10.0pt;font-family:Arial;color:navy'><o:p> </o:p></= span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span lang=3D= EN style=3D'font-size:10.0pt;font-family:Arial;color:navy'>Georg<o:p></o:p></s= pan></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3D"Times New Roman"><= span style=3D'font-size:10.0pt;color:navy'><o:p> </o:p></span></font></p> </div> <div> <div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font siz= e=3D3 face=3D"Times New Roman"><span style=3D'font-size:12.0pt'> <hr size=3D2 width=3D"100%" align=3Dcenter tabindex=3D-1> </span></font></div> <p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span style=3D'font-si= ze:10.0pt; font-family:Tahoma;font-weight:bold'>From:</span></font></b><font face=3DTa= homa><span style=3D'font-family:Tahoma'> Laganier, Julien [mailto:julienl@qualcomm.com= ] <br> <b><span style=3D'font-weight:bold'>Sent:</span></b> Thursday, January 20, = 2011 4:27 PM<br> <b><span style=3D'font-weight:bold'>To:</span></b> Hampel, K Georg (K Georg= ); mext@ietf.org<br> <b><span style=3D'font-weight:bold'>Cc:</span></b> Klein, Thierry E (Thierr= y)<br> <b><span style=3D'font-weight:bold'>Subject:</span></b> RE: Support of rout= e optimization in *absence* of HA</span></font><font size=3D3><span style=3D'font-size:12.0pt'><o:p></o:p></span></font></p> </div> <p class=3DMsoNormal><font size=3D2 face=3D"Times New Roman"><span style=3D= 'font-size: 10.0pt'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" face=3DCalibri><span style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'>Georg,<o:p></o= :p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" face=3DCalibri><span style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'><o:p> </o= :p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" face=3DCalibri><span style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'>Is it correct = that functionally your proposal is similar to Homeless Mobile IPv6:<o:p></o:p></= span></font></p> <p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" face=3DCalibri><span style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'><o:p> </o= :p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3D"Times New Roman"><span style=3D= 'font-size: 10.0pt'><a href=3D"http://tools.ietf.org/html/draft-nikander-mobileip-homelessv6-01">h= ttp://tools.ietf.org/html/draft-nikander-mobileip-homelessv6-01</a><o:p></o= :p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3D"Times New Roman"><span style=3D= 'font-size: 10.0pt'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" face=3DCalibri><span style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'>Best,<o:p></o:= p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" face=3DCalibri><span style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'><o:p> </o= :p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" face=3DCalibri><span style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'>--julien<o:p><= /o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" face=3DCalibri><span style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'><o:p> </o= :p></span></font></p> <div style=3D'border:none;border-left:solid blue 1.5pt;padding:0pt 0pt 0pt = 4.0pt'> <div> <div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0pt = 0pt 0pt'> <p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span style=3D'font-si= ze:10.0pt; font-family:Tahoma;font-weight:bold'>From:</span></font></b><font face=3DTa= homa><span style=3D'font-family:Tahoma'> mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] <b><span style=3D'font-weight:bold'>On Behal= f Of </span></b>Hampel, K Georg (K Georg)<br> <b><span style=3D'font-weight:bold'>Sent:</span></b> Thursday, January 20, = 2011 12:07 PM<br> <b><span style=3D'font-weight:bold'>To:</span></b> mext@ietf.org<br> <b><span style=3D'font-weight:bold'>Cc:</span></b> Hampel, K Georg (K Georg= ); Klein, Thierry E (Thierry)<br> <b><span style=3D'font-weight:bold'>Subject:</span></b> [MEXT] Support of r= oute optimization in *absence* of HA<o:p></o:p></span></font></p> </div> </div> <p class=3DMsoNormal><font size=3D2 face=3D"Times New Roman"><span style=3D= 'font-size: 10.0pt'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1= 0.5pt; font-family:Arial'>All,<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1= 0.5pt; font-family:Arial'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1= 0.5pt; font-family:Arial'>We would like to add a proposal to MEXT that permits the mobile to engage into route-optimization in *absence* of a home agent. <o:p= ></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1= 0.5pt; font-family:Arial'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1= 0.5pt; font-family:Arial'>Such a feature adds robustness to route optimization in = case the HA is temporarily unavailable. Under some circumstances, route optimiza= tion *without* HA may be beneficial for performance reasons. Our proposal requir= es “enhanced route optimization for Mobile IPv6” (RFC 4866) as pre= -requisite.<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1= 0.5pt; font-family:Arial'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1= 0.5pt; font-family:Arial'>We would like to obtain some feedback from the MEXT community via this mailing list before we submit the proposal as a draft to= the workgroup. For this purpose, we have enclosed a high-level outline below. Thanks.<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1= 0.5pt; font-family:Arial'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1= 0.5pt; font-family:Arial'>Regards,<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1= 0.0pt; font-family:Arial'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1= 0.0pt; font-family:Arial'>Georg Hampel<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1= 0.0pt; font-family:Arial'>Networking & Networks Domain<o:p></o:p></span></font= ></p> <p class=3DMsoNormal><st1:City w:st=3D"on"><st1:place w:st=3D"on"><font siz= e=3D2 face=3DArial><span style=3D'font-size:10.0pt;font-family:Arial'>Bell</spa= n></font></st1:place></st1:City><font face=3DArial><span style=3D'font-family:Arial'> Laboratories<o:p></o:p></sp= an></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1= 0.0pt; font-family:Arial'>Alcatel-Lucent<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1= 0.0pt; font-family:Arial'>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1= 0.0pt; font-family:Arial'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1= 0.5pt; font-family:Arial'>Proposal: Support of Route-Optimization in Absence of Ho= me Agent<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1= 0.5pt; font-family:Arial'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1= 0.5pt; font-family:Arial'>ABSTRACT:<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1= 0.5pt; font-family:Arial'>The proposal allows the mobile to engage into route optimization (R/O) in *absence* of a HA. This feature increases robustness = when the HA becomes temporarily unavailable. Under some circumstances, R/O *with= out* HA may be beneficial for performance reasons. This proposal requires “= ;enhanced route optimization for Mobile IPv6” (RFC 4866) as pre-requisite. <o:p= ></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1= 0.5pt; font-family:Arial'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1= 0.5pt; font-family:Arial'>MOTIVATION:<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1= 0.5pt; font-family:Arial'>In route optimization (R/O), traffic packets are directl= y exchanged between hosts without passing the HA. The mobile, however, still = has to interact with the HA. The HA provides (1) location service, (2) a fallba= ck path in case the direct path breaks, (3) a fallback in case the corresponde= nt does not support the protocol and (4) security support for R/O-related signaling (i.e. home test). These functions come at the following cost:<o:p= ></o:p></span></font></p> <p class=3DMsoNormal style=3D'margin-left:14.0pt;text-indent:-14.0pt;mso-li= st:l3 level1 lfo2'><![if !supportLists]><font size=3D1 face=3DSymbol><span style=3D'font-size:9.0pt;font-family:Symbol'><= span style=3D'mso-list:Ignore'>·<font size=3D1 face=3D"Times New Roman"><= span style=3D'font:7.0pt "Times New Roman"'>      = </span></font></span></span></font><![endif]><font size=3D2 face=3DArial><span style=3D'font-size:10.5pt;font-family:Arial'>Ha= ndovers may fail when the link to the HA or the HA itself are down or congested. Mobility is not supported, when the mobile does not have a HA.<o:p></o:p></= span></font></p> <p class=3DMsoNormal style=3D'margin-left:14.0pt;text-indent:-14.0pt;mso-li= st:l3 level1 lfo2'><![if !supportLists]><font size=3D1 face=3DSymbol><span style=3D'font-size:9.0pt;font-family:Symbol'><= span style=3D'mso-list:Ignore'>·<font size=3D1 face=3D"Times New Roman"><= span style=3D'font:7.0pt "Times New Roman"'>      = </span></font></span></span></font><![endif]><font size=3D2 face=3DArial><span style=3D'font-size:10.5pt;font-family:Arial'>Wh= en the mobile starts a session outside of its home network, it must use a HoA pertaining to its home network even if it engages into R/O. This requiremen= t adds air-interface overhead due to mobility headers and processing overhead= on the mobile. This upfront cost incurs even if the mobile does not move durin= g the session.<o:p></o:p></span></font></p> <p class=3DMsoNormal style=3D'margin-left:14.0pt;text-indent:-14.0pt;mso-li= st:l3 level1 lfo2'><![if !supportLists]><font size=3D1 face=3DSymbol><span style=3D'font-size:9.0pt;font-family:Symbol'><= span style=3D'mso-list:Ignore'>·<font size=3D1 face=3D"Times New Roman"><= span style=3D'font:7.0pt "Times New Roman"'>      = </span></font></span></span></font><![endif]><font size=3D2 face=3DArial><span style=3D'font-size:10.5pt;font-family:Arial'>Si= gnaling handshakes have to be conducted between mobile and HA at every mobility eve= nt.<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1= 0.5pt; font-family:Arial'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1= 0.5pt; font-family:Arial'>Currently, the Mobile IPv6 standard family forces the mo= bile to bear these disadvantages in R/O even if the HA functions are not needed. This specifically applies to scenarios where: <o:p></o:p></span></font></p> <p class=3DMsoNormal style=3D'margin-left:14.0pt;text-indent:-14.0pt;mso-li= st:l0 level1 lfo4'><![if !supportLists]><font size=3D1 face=3DSymbol><span style=3D'font-size:9.0pt;font-family:Symbol'><= span style=3D'mso-list:Ignore'>·<font size=3D1 face=3D"Times New Roman"><= span style=3D'font:7.0pt "Times New Roman"'>      = </span></font></span></span></font><![endif]><font size=3D2 face=3DArial><span style=3D'font-size:10.5pt;font-family:Arial'>Tr= affic is based on mobile-initiated requests to public servers (majority of present mobile internet traffic). The HA’s location service is not needed for= such traffic. Location service may also be provided by other means such as Dynam= ic DNS or on application layer (e.g. SIP registrar).<o:p></o:p></span></font><= /p> <p class=3DMsoNormal style=3D'margin-left:14.0pt;text-indent:-14.0pt;mso-li= st:l0 level1 lfo4'><![if !supportLists]><font size=3D1 face=3DSymbol><span style=3D'font-size:9.0pt;font-family:Symbol'><= span style=3D'mso-list:Ignore'>·<font size=3D1 face=3D"Times New Roman"><= span style=3D'font:7.0pt "Times New Roman"'>      = </span></font></span></span></font><![endif]><font size=3D2 face=3DArial><span style=3D'font-size:10.5pt;font-family:Arial'>Th= e fallback path through the HA has little value when it shares the weakest link with t= he direct path. Since the weakest link is typically the wireless link, this situation applies to all scenarios where only one air interface is availabl= e (this is the typical case rather than the exception).<o:p></o:p></span></fo= nt></p> <p class=3DMsoNormal style=3D'margin-left:14.0pt;text-indent:-14.0pt;mso-li= st:l0 level1 lfo4'><![if !supportLists]><font size=3D1 face=3DSymbol><span style=3D'font-size:9.0pt;font-family:Symbol'><= span style=3D'mso-list:Ignore'>·<font size=3D1 face=3D"Times New Roman"><= span style=3D'font:7.0pt "Times New Roman"'>      = </span></font></span></span></font><![endif]><font size=3D2 face=3DArial><span style=3D'font-size:10.5pt;font-family:Arial'>Th= e mobile may know about the correspondent’s Mobile-IPv6 support from prior ses= sions or through means external to the standard. <o:p></o:p></span></font></p> <p class=3DMsoNormal style=3D'margin-left:14.0pt;text-indent:-14.0pt;mso-li= st:l0 level1 lfo4'><![if !supportLists]><font size=3D1 face=3DSymbol><span style=3D'font-size:9.0pt;font-family:Symbol'><= span style=3D'mso-list:Ignore'>·<font size=3D1 face=3D"Times New Roman"><= span style=3D'font:7.0pt "Times New Roman"'>      = </span></font></span></span></font><![endif]><font size=3D2 face=3DArial><span style=3D'font-size:10.5pt;font-family:Arial'>Th= e mobile applies the CGA-based procedure of RFC 4866, which makes the HA’s sec= urity support for R/O unnecessary. This applies to all cases where stateless addressing is permitted. <o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1= 0.5pt; font-family:Arial'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1= 0.5pt; font-family:Arial'>To increase the flexibility and robustness of route-optimized Mobile IPv6, we propose to make the HA an *optional* rather than a *mandatory* feature, i.e. to permit operation without HA. This propo= sal requires some additional extensions to the present standard.<o:p></o:p></sp= an></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1= 0.5pt; font-family:Arial'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1= 0.5pt; font-family:Arial'>HIGH-LEVEL OUTLINE<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1= 0.5pt; font-family:Arial'>The extensions build on Enhanced Route Optimization for Mobile IPv6 (RFC 4866) to guarantee sufficient signaling security. With the absence of a HA, mobility support in R/O can be provided in the following manner:<o:p></o:p></span></font></p> <p class=3DMsoNormal style=3D'margin-left:14.0pt;text-indent:-14.0pt;mso-li= st:l1 level1 lfo6'><![if !supportLists]><font size=3D1 face=3DSymbol><span style=3D'font-size:9.0pt;font-family:Symbol'><= span style=3D'mso-list:Ignore'>·<font size=3D1 face=3D"Times New Roman"><= span style=3D'font:7.0pt "Times New Roman"'>      = </span></font></span></span></font><![endif]><font size=3D2 face=3DArial><span style=3D'font-size:10.5pt;font-family:Arial'>Th= e mobile starts the traffic session from any of its currently supported IP addresses= . The selected IP address automatically takes the function of the HoA for thi= s session. This has the advantage that conventional transport is used as long= as the mobile does not move, i.e. mobility headers and CoA-vs-HoA mapping is n= ot needed. The HoA must have been generated via CGA in compliance with RFC 486= 6. <o:p></o:p></span></font></p> <p class=3DMsoNormal style=3D'margin-left:14.0pt;text-indent:-14.0pt;mso-li= st:l1 level1 lfo6'><![if !supportLists]><font size=3D1 face=3DSymbol><span style=3D'font-size:9.0pt;font-family:Symbol'><= span style=3D'mso-list:Ignore'>·<font size=3D1 face=3D"Times New Roman"><= span style=3D'font:7.0pt "Times New Roman"'>      = </span></font></span></span></font><![endif]><font size=3D2 face=3DArial><span style=3D'font-size:10.5pt;font-family:Arial'>Th= e mobile must conduct a “home-test” from this HoA in compliance with RFC= 4866. It may conduct the home-test prior to session establishment, e.g. to find out if t= he correspondent supports the standard. <o:p></o:p></span></font></p> <p class=3DMsoNormal style=3D'margin-left:14.0pt;text-indent:-14.0pt;mso-li= st:l1 level1 lfo6'><![if !supportLists]><font size=3D1 face=3DSymbol><span style=3D'font-size:9.0pt;font-family:Symbol'><= span style=3D'mso-list:Ignore'>·<font size=3D1 face=3D"Times New Roman"><= span style=3D'font:7.0pt "Times New Roman"'>      = </span></font></span></span></font><![endif]><font size=3D2 face=3DArial><span style=3D'font-size:10.5pt;font-family:Arial'>Al= l binding update handshakes are conducted on the direct path according to RFC 4866.<o= :p></o:p></span></font></p> <p class=3DMsoNormal style=3D'margin-left:14.0pt;text-indent:-14.0pt;mso-li= st:l1 level1 lfo6'><![if !supportLists]><font size=3D1 face=3DSymbol><span style=3D'font-size:9.0pt;font-family:Symbol'><= span style=3D'mso-list:Ignore'>·<font size=3D1 face=3D"Times New Roman"><= span style=3D'font:7.0pt "Times New Roman"'>      = </span></font></span></span></font><![endif]><font size=3D2 face=3DArial><span style=3D'font-size:10.5pt;font-family:Arial'>Si= nce sessions are always started from a currently supported IP address, temporal= ly overlapping sessions may use different HoAs. A multi-homed mobile may also decide to start sessions from different simultaneously supported IP address= es. There is no principle problem here.<o:p></o:p></span></font></p> <p class=3DMsoNormal style=3D'margin-left:14.0pt;text-indent:-14.0pt;mso-li= st:l1 level1 lfo6'><![if !supportLists]><font size=3D1 face=3DSymbol><span style=3D'font-size:9.0pt;font-family:Symbol'><= span style=3D'mso-list:Ignore'>·<font size=3D1 face=3D"Times New Roman"><= span style=3D'font:7.0pt "Times New Roman"'>      = </span></font></span></span></font><![endif]><font size=3D2 face=3DArial><span style=3D'font-size:10.5pt;font-family:Arial'>Op= posed to RFC 4866, the mobile need not perform the CoA registration with the HA.<o:p= ></o:p></span></font></p> <p class=3DMsoNormal style=3D'margin-left:14.0pt;text-indent:-14.0pt;mso-li= st:l1 level1 lfo6'><![if !supportLists]><font size=3D1 face=3DSymbol><span style=3D'font-size:9.0pt;font-family:Symbol'><= span style=3D'mso-list:Ignore'>·<font size=3D1 face=3D"Times New Roman"><= span style=3D'font:7.0pt "Times New Roman"'>      = </span></font></span></span></font><![endif]><font size=3D2 face=3DArial><span style=3D'font-size:10.5pt;font-family:Arial'>Th= e mobile must be able to deregister the HoA at the correspondent in case the HoA is = not supported anymore. This ensures that the correspondent does not send packet= s to the HoA. After deregistration of the HoA, the HoA is still used by higher protocol layers of ongoing sessions. It must still be included in the mobil= ity headers for these sessions.<o:p></o:p></span></font></p> <p class=3DMsoNormal style=3D'margin-left:14.0pt;text-indent:-14.0pt;mso-li= st:l1 level1 lfo6'><![if !supportLists]><font size=3D1 face=3DSymbol><span style=3D'font-size:9.0pt;font-family:Symbol'><= span style=3D'mso-list:Ignore'>·<font size=3D1 face=3D"Times New Roman"><= span style=3D'font:7.0pt "Times New Roman"'>      = </span></font></span></span></font><![endif]><font size=3D2 face=3DArial><span style=3D'font-size:10.5pt;font-family:Arial'>Wh= en the mobile has HA support and the HA becomes temporarily unavailable, the mobil= e simply continues R/O without HA as outlined in the prior points.<o:p></o:p>= </span></font></p> <p class=3DMsoNormal style=3D'margin-left:14.0pt;text-indent:-14.0pt;mso-li= st:l1 level1 lfo6'><![if !supportLists]><font size=3D1 face=3DSymbol><span style=3D'font-size:9.0pt;font-family:Symbol'><= span style=3D'mso-list:Ignore'>·<font size=3D1 face=3D"Times New Roman"><= span style=3D'font:7.0pt "Times New Roman"'>      = </span></font></span></span></font><![endif]><font size=3D2 face=3DArial><span style=3D'font-size:10.5pt;font-family:Arial'>Th= e mobile can publish its IP address in any location service. This allows other hosts= to initiate sessions with the mobile. These sessions enjoy route-optimized mobility support only if the published IP address was generated via CGA in compliance with RFC 4866.<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1= 0.5pt; font-family:Arial'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1= 0.5pt; font-family:Arial'>OPEN ISSUES<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1= 0.5pt; font-family:Arial'>These extensions have to be made compliant with RFC 5648 (multiple CoA registration), RFC 3963 (NEMO) and others. More discussions a= re necessary.<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1= 0.5pt; font-family:Arial'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1= 0.5pt; font-family:Arial'><o:p> </o:p></span></font></p> </div> </div> </body> </html> --_000_154773479ED2314980CB638A48FC44348334CFA1USNAVSXCHMBSA2n_-- From georg.hampel@alcatel-lucent.com Thu Jan 20 17:24:54 2011 Return-Path: <georg.hampel@alcatel-lucent.com> X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 043E93A687C for <mext@core3.amsl.com>; Thu, 20 Jan 2011 17:24:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0qjdlcoVp4V7 for <mext@core3.amsl.com>; Thu, 20 Jan 2011 17:24:53 -0800 (PST) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by core3.amsl.com (Postfix) with ESMTP id 174373A6858 for <mext@ietf.org>; Thu, 20 Jan 2011 17:24:53 -0800 (PST) Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id p0L1Rbqw022881 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <mext@ietf.org>; Thu, 20 Jan 2011 19:27:37 -0600 (CST) Received: from USNAVSXCHHUB03.ndc.alcatel-lucent.com (usnavsxchhub03.ndc.alcatel-lucent.com [135.3.39.112]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p0L1RbiB013682 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for <mext@ietf.org>; Thu, 20 Jan 2011 19:27:37 -0600 Received: from USNAVSXCHMBSA2.ndc.alcatel-lucent.com ([135.3.39.127]) by USNAVSXCHHUB03.ndc.alcatel-lucent.com ([135.3.39.112]) with mapi; Thu, 20 Jan 2011 19:27:36 -0600 From: "Hampel, K Georg (K Georg)" <georg.hampel@alcatel-lucent.com> To: "mext@ietf.org" <mext@ietf.org> Date: Thu, 20 Jan 2011 19:27:36 -0600 Thread-Topic: reduce mobility header size Thread-Index: Acu5CmJdbSxQl612R5mxNxDpv0tWng== Message-ID: <154773479ED2314980CB638A48FC44348334CFA2@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_154773479ED2314980CB638A48FC44348334CFA2USNAVSXCHMBSA2n_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.9 Cc: "Klein, Thierry E \(Thierry\)" <thierry.klein@alcatel-lucent.com> Subject: [MEXT] reduce mobility header size X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG <mext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/mext> List-Post: <mailto:mext@ietf.org> List-Help: <mailto:mext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 21 Jan 2011 01:24:54 -0000 --_000_154773479ED2314980CB638A48FC44348334CFA2USNAVSXCHMBSA2n_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, Is there currently any effort to reduce the mobility header size in route o= ptimization? Thanks. Georg Hampel --_000_154773479ED2314980CB638A48FC44348334CFA2USNAVSXCHMBSA2n_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns=3D"http://www.w3.org/TR/REC-html40"> <head> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; charset=3Dus-ascii"= > <meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)"> <style> <!-- /* Font Definitions */ @font-face {font-family:SimSun; panose-1:2 1 6 0 3 1 1 1 1 1;} @font-face {font-family:"\@SimSun"; panose-1:2 1 6 0 3 1 1 1 1 1;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0pt; margin-bottom:.0001pt; font-size:10.0pt; font-family:"Times New Roman";} a:link, span.MsoHyperlink {color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {color:purple; text-decoration:underline;} span.EmailStyle17 {mso-style-type:personal-compose; font-family:Arial; color:windowtext;} @page Section1 {size:612.0pt 792.0pt; margin:72.0pt 90.0pt 72.0pt 90.0pt;} div.Section1 {page:Section1;} --> </style> <!--[if gte mso 9]><xml> <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext=3D"edit"> <o:idmap v:ext=3D"edit" data=3D"1" /> </o:shapelayout></xml><![endif]--> </head> <body lang=3DEN-US link=3Dblue vlink=3Dpurple> <div class=3DSection1> <p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1= 0.0pt; font-family:Arial'>All,<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1= 0.0pt; font-family:Arial'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1= 0.0pt; font-family:Arial'>Is there currently any effort to reduce the mobility hea= der size in route optimization? Thanks.<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1= 0.0pt; font-family:Arial'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1= 0.0pt; font-family:Arial'>Georg Hampel</span></font><o:p></o:p></p> <p class=3DMsoNormal><font size=3D2 face=3D"Times New Roman"><span style=3D= 'font-size: 10.0pt'><o:p> </o:p></span></font></p> </div> </body> </html> --_000_154773479ED2314980CB638A48FC44348334CFA2USNAVSXCHMBSA2n_-- From arno@natisbad.org Fri Jan 21 00:06:22 2011 Return-Path: <arno@natisbad.org> X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 63BE03A68E0 for <mext@core3.amsl.com>; Fri, 21 Jan 2011 00:06:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HWE-xKUJLANd for <mext@core3.amsl.com>; Fri, 21 Jan 2011 00:06:20 -0800 (PST) Received: from copper.chdir.org (copper.chdir.org [88.191.97.87]) by core3.amsl.com (Postfix) with ESMTP id AA51C3A68D9 for <mext@ietf.org>; Fri, 21 Jan 2011 00:06:20 -0800 (PST) Received: from enough (unknown [IPv6:2001:7a8:1161:20:baac:6fff:fe41:5166]) by copper.chdir.org (Postfix) with ESMTPSA id 11826450053; Fri, 21 Jan 2011 09:09:03 +0100 (CET) From: arno@natisbad.org (Arnaud Ebalard) To: "Hampel\, K Georg \(K Georg\)" <georg.hampel@alcatel-lucent.com> References: <154773479ED2314980CB638A48FC44348334CFA2@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> X-PGP-Key-URL: http://natisbad.org/arno@natisbad.org.asc X-Fingerprint: D3A5 B68A 839B 38A5 815A 781B B77C 0748 A7AE 341B X-Hashcash: 1:20:110121:mext@ietf.org::FGMO0BQH+8GwjWaW:00000F8J X-Hashcash: 1:20:110121:thierry.klein@alcatel-lucent.com::RNluKEAi1wJ3xcsl:000000000000000000000000000000yjN X-Hashcash: 1:20:110121:georg.hampel@alcatel-lucent.com::BPk01SPmuxI6TyH+:0000000000000000000000000000005HcH Date: Fri, 21 Jan 2011 09:04:02 +0100 In-Reply-To: <154773479ED2314980CB638A48FC44348334CFA2@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> (K. Georg Hampel's message of "Thu, 20 Jan 2011 19:27:36 -0600") Message-ID: <87d3nq3cp9.fsf@natisbad.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "Klein, Thierry E \(Thierry\)" <thierry.klein@alcatel-lucent.com>, "mext@ietf.org" <mext@ietf.org> Subject: Re: [MEXT] reduce mobility header size X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG <mext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/mext> List-Post: <mailto:mext@ietf.org> List-Help: <mailto:mext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 21 Jan 2011 08:06:22 -0000 Hi, "Hampel, K Georg (K Georg)" <georg.hampel@alcatel-lucent.com> writes: > Is there currently any effort to reduce the mobility header size in > route optimization? Thanks. Do you mean the presence of RH2 and HAO in DestOpt in the packets? If you intend *to use IPsec/IKE between the peers*, I proposed a solution to remove RH2 and HAO in DestOpt from packets and also the need for HoTI/HoT in the following draft: http://tools.ietf.org/html/draft-ebalard-mext-ipsec-ro-02 For a simple introduction (description, advantages, drawbacks), http://natisbad.org/IRO/ Cheers, a+ From alexandru.petrescu@gmail.com Fri Jan 21 06:48:57 2011 Return-Path: <alexandru.petrescu@gmail.com> X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D53E83A6918 for <mext@core3.amsl.com>; Fri, 21 Jan 2011 06:48:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.049 X-Spam-Level: X-Spam-Status: No, score=-2.049 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c64hIZrc0Y0p for <mext@core3.amsl.com>; Fri, 21 Jan 2011 06:48:56 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.166.172.107]) by core3.amsl.com (Postfix) with ESMTP id 324343A6994 for <mext@ietf.org>; Fri, 21 Jan 2011 06:48:56 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id p0LEpe2F013957 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 21 Jan 2011 15:51:40 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id p0LEpeDK016223; Fri, 21 Jan 2011 15:51:40 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [132.166.133.173] (is010173.intra.cea.fr [132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id p0LEpeNT004171; Fri, 21 Jan 2011 15:51:40 +0100 Message-ID: <4D399D7C.6070503@gmail.com> Date: Fri, 21 Jan 2011 15:51:40 +0100 From: Alexandru Petrescu <alexandru.petrescu@gmail.com> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: mext@ietf.org References: <154773479ED2314980CB638A48FC44348334CE4F@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> In-Reply-To: <154773479ED2314980CB638A48FC44348334CE4F@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [MEXT] Support of route optimization in *absence* of HA X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG <mext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/mext> List-Post: <mailto:mext@ietf.org> List-Help: <mailto:mext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 21 Jan 2011 14:48:57 -0000 Hello and thanks for this message, I think generally Route Optimization in the absence of a Home Agent is a useful matter to address. With colleagues I have worked on a solution whereby two Mobile Routers can communicate directly via their egress interface, bypassing the need to contact the Home Agent: http://tools.ietf.org/html/draft-petrescu-autoconf-ra-based-routing-00 (the draft is being updated with transportation scenarios and expanded authorship, and I would be interested to discuss it further). In a certain sense this MR-to-MR can be considered as Route Optimization without using Home Agent, although it is at a certain extreme where no Home Addresses/CoAs are used either. A related draft MNPP does a similar behaviour, but it has an additional scenario with a fixed Access Point: http://tools.ietf.org/html/draft-jhlee-mext-mnpp-00 I insert below some comments on the preliminary text you provided: Le 20/01/2011 21:07, Hampel, K Georg (K Georg) a écrit : > All, > > We would like to add a proposal to MEXT that permits the mobile to > engage into route-optimization in *absence* of a home agent. > > Such a feature adds robustness to route optimization in case the HA > is temporarily unavailable. Under some circumstances, route > optimization *without* HA may be beneficial for performance reasons. > Our proposal requires “enhanced route optimization for Mobile IPv6” > (RFC 4866) as pre-requisite. > > We would like to obtain some feedback from the MEXT community via > this mailing list before we submit the proposal as a draft to the > workgroup. For this purpose, we have enclosed a high-level outline > below. Thanks. > > Regards, > > Georg Hampel > > Networking & Networks Domain > > BellLaboratories > > Alcatel-Lucent > > ============================================ > > Proposal: Support of Route-Optimization in Absence of Home Agent > > ABSTRACT: > > The proposal allows the mobile to engage into route optimization > (R/O) in *absence* of a HA. This feature increases robustness when > the HA becomes temporarily unavailable. Under some circumstances, R/O > *without* HA may be beneficial for performance reasons. This is a good point - it is very advantageous to perform direct MN-to-MN communication some times when HA is little or not available at all. > This proposal requires “enhanced route optimization for Mobile IPv6” > (RFC 4866) as pre-requisite. I must say I do not understand why this RFC is required. Is your proposal intended to become an extension of RFC4866? > MOTIVATION: > > In route optimization (R/O), traffic packets are directly exchanged > between hosts without passing the HA. The mobile, however, still has > to interact with the HA. The HA provides (1) location service, (2) a > fallback path in case the direct path breaks, (3) a fallback in case > the correspondent does not support the protocol and (4) security > support for R/O-related signaling (i.e. home test). YEs, the first step (1) is the fact establishing the initial BC entries (the ones permitting direct non-tunnelled communication CoA to CoA on behalf of the HoAs) is impossible if HA does not reply. Once the BC entries are established the HA is no longer needed. > These functions come at the following cost: > > ·Handovers may fail when the link to the HA or the HA itself are down > or congested. Mobility is not supported, when the mobile does not > have a HA. I agree, this is an excellent point. Lack of HA forbidding network-layer communication upon handover is an unfortunate consequence of cross-layer otherwise abberant tunnel assumptions. Tunnels have a magic in them (go up next level( but they also expose their weaknesses when least expected. > ·When the mobile starts a session outside of its home network, it > must use a HoA pertaining to its home network even if it engages into > R/O. This requirement adds air-interface overhead due to mobility > headers and processing overhead on the mobile. This upfront cost > incurs even if the mobile does not move during the session. Is this the HoA in the Routing Header being a packet size problem? > ·Signaling handshakes have to be conducted between mobile and HA at > every mobility event. This is a cost? yes and no. BU/BAck and RR messages happen relatively fast compared to RS/RA address autoconfig, and the link-layer messages used during handovers for configuration and security. The Mobile IPv6 signalling represents less than 10% from the handover time, even in the unfortunate cases when HA is very far away in the Internet. In another sense, it is good to optimize out even these 10%. Also, if you start saying MIPv6 signalling is a "cost" (a negative) then make sure you don't design something new which actually has a higher cost. You risk struggling against a cost which is already very low (Mobile IPv6 BU/BAck RR message exchange cost is very low). > Currently, the Mobile IPv6 standard family forces the mobile to bear > these disadvantages in R/O even if the HA functions are not needed. > This specifically applies to scenarios where: > > ·Traffic is based on mobile-initiated requests to public servers > (majority of present mobile internet traffic). The HA’s location > service is not needed for such traffic. Location service may also be > provided by other means such as Dynamic DNS or on application layer > (e.g. SIP registrar). YEs, I agree, one wouldn't need the MH to use its HoA when talking some web browsing to a local server. > ·The fallback path through the HA has little value when it shares the > weakest link with the direct path. Since the weakest link is > typically the wireless link, this situation applies to all scenarios > where only one air interface is available (this is the typical case > rather than the exception). I need to better understand this. What is the "direct path"? I understand "fallback path" being to HA. I would need further explanation of this item. > ·The mobile may know about the correspondent’s Mobile-IPv6 support > from prior sessions or through means external to the standard. A-ha, so there are scenarios where the MHs may know each other's CoA/HoAs pre-configured somehow. > ·The mobile applies the CGA-based procedure of RFC 4866, which makes > the HA’s security support for R/O unnecessary. This applies to all > cases where stateless addressing is permitted. Do we need to limit an HA-less RO mechanism to using CGA? Would this work without CGA? > To increase the flexibility and robustness of route-optimized Mobile > IPv6, we propose to make the HA an *optional* rather than a > *mandatory* feature, i.e. to permit operation without HA. This > proposal requires some additional extensions to the present > standard. So you want to design an RFC4866bis? > HIGH-LEVEL OUTLINE > > The extensions build on Enhanced Route Optimization for Mobile IPv6 > (RFC 4866) to guarantee sufficient signaling security. With the > absence of a HA, mobility support in R/O can be provided in the > following manner: > > ·The mobile starts the traffic session from any of its currently > supported IP addresses. The selected IP address automatically takes > the function of the HoA for this session. This has the advantage that > conventional transport is used as long as the mobile does not move, > i.e. mobility headers and CoA-vs-HoA mapping is not needed. The HoA > must have been generated via CGA in compliance with RFC 4866. > > ·The mobile must conduct a “home-test” from this HoA in compliance > with RFC 4866. It may conduct the home-test prior to session > establishment, e.g. to find out if the correspondent supports the > standard. > > ·All binding update handshakes are conducted on the direct path > according to RFC 4866. > > ·Since sessions are always started from a currently supported IP > address, temporally overlapping sessions may use different HoAs. A > multi-homed mobile may also decide to start sessions from different > simultaneously supported IP addresses. There is no principle problem > here. > > ·Opposed to RFC 4866, the mobile need not perform the CoA > registration with the HA. > > ·The mobile must be able to deregister the HoA at the correspondent > in case the HoA is not supported anymore. This ensures that the > correspondent does not send packets to the HoA. After deregistration > of the HoA, the HoA is still used by higher protocol layers of > ongoing sessions. It must still be included in the mobility headers > for these sessions. > > ·When the mobile has HA support and the HA becomes temporarily > unavailable, the mobile simply continues R/O without HA as outlined > in the prior points. > > ·The mobile can publish its IP address in any location service. This > allows other hosts to initiate sessions with the mobile. These > sessions enjoy route-optimized mobility support only if the published > IP address was generated via CGA in compliance with RFC 4866. This is a technique, yes. Is RFC4866 more implemented than MIPv6 RR? > OPEN ISSUES > > These extensions have to be made compliant with RFC 5648 (multiple > CoA registration), RFC 3963 (NEMO) and others. More discussions are > necessary. I agree. Alex > > > > _______________________________________________ MEXT mailing list > MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From alexandru.petrescu@gmail.com Fri Jan 21 06:55:18 2011 Return-Path: <alexandru.petrescu@gmail.com> X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A316E3A6962 for <mext@core3.amsl.com>; Fri, 21 Jan 2011 06:55:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mYob-F6Ri3FN for <mext@core3.amsl.com>; Fri, 21 Jan 2011 06:55:17 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.1]) by core3.amsl.com (Postfix) with ESMTP id 98D543A6908 for <mext@ietf.org>; Fri, 21 Jan 2011 06:55:17 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id p0LEw2AT014459 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 21 Jan 2011 15:58:02 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id p0LEw2e1018931; Fri, 21 Jan 2011 15:58:02 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [132.166.133.173] (is010173.intra.cea.fr [132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id p0LEw2T0007461; Fri, 21 Jan 2011 15:58:02 +0100 Message-ID: <4D399EFA.1070701@gmail.com> Date: Fri, 21 Jan 2011 15:58:02 +0100 From: Alexandru Petrescu <alexandru.petrescu@gmail.com> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: mext@ietf.org References: <154773479ED2314980CB638A48FC44348334CFA2@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> In-Reply-To: <154773479ED2314980CB638A48FC44348334CFA2@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [MEXT] reduce mobility header size X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG <mext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/mext> List-Post: <mailto:mext@ietf.org> List-Help: <mailto:mext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 21 Jan 2011 14:55:18 -0000 HEllo, Generally speaking it is a very good intention to reduce the mobility header size as much as possible. For IPv6 the problem is all the more important knowing the addresses are 4 times longer than IPv4. But also in IPv4 there are intentions to reduce the headers during Mobile IPv4 handovers (e.g. handover from NAT to non-NAT should use the smaller header). When you say "reduce MH size in RO" do you mean the headers of the Return Routability tests? Or the headers of data direct path communication after RR was performed? Alex Le 21/01/2011 02:27, Hampel, K Georg (K Georg) a écrit : > All, > > Is there currently any effort to reduce the mobility header size in > route optimization? Thanks. > > Georg Hampel > > > > _______________________________________________ MEXT mailing list > MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From alexandru.petrescu@gmail.com Fri Jan 21 07:19:32 2011 Return-Path: <alexandru.petrescu@gmail.com> X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D079E3A6A12 for <mext@core3.amsl.com>; Fri, 21 Jan 2011 07:19:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.129 X-Spam-Level: X-Spam-Status: No, score=-2.129 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j0Wg7t+8vg0X for <mext@core3.amsl.com>; Fri, 21 Jan 2011 07:19:31 -0800 (PST) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.166.172.106]) by core3.amsl.com (Postfix) with ESMTP id 036133A6A00 for <mext@ietf.org>; Fri, 21 Jan 2011 07:19:30 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id p0LFME7S019105 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 21 Jan 2011 16:22:14 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id p0LFMEJh029317; Fri, 21 Jan 2011 16:22:14 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [132.166.133.173] (is010173.intra.cea.fr [132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id p0LFMEs0006204; Fri, 21 Jan 2011 16:22:14 +0100 Message-ID: <4D39A4A6.5030903@gmail.com> Date: Fri, 21 Jan 2011 16:22:14 +0100 From: Alexandru Petrescu <alexandru.petrescu@gmail.com> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: mext@ietf.org References: <154773479ED2314980CB638A48FC44348334CE4F@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <98A16B2D00B5724F81E80EF1927A0297036BB6@nasanexd01e.na.qualcomm.com> <154773479ED2314980CB638A48FC44348334CFA1@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> In-Reply-To: <154773479ED2314980CB638A48FC44348334CFA1@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [MEXT] Support of route optimization in *absence* of HA X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG <mext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/mext> List-Post: <mailto:mext@ietf.org> List-Help: <mailto:mext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 21 Jan 2011 15:19:32 -0000 Le 21/01/2011 02:24, Hampel, K Georg (K Georg) a écrit : > Julien, > > The intentions of Homeless MIPv6 are similar to those of our > proposal. > > In contrast to Homeless MIPv6, our proposal requires only minimal > upgrades to the present standard and implementation. (Homeless MIPv6 > requires changes to the TCP/UDP and requires AH, for instance). > > Here’s the core idea of HA-free R/O: > > 1)When starting a session, the MN self-declares its current IP > address as the “HoA” for this session. This automatically means that > it resides in its “home network” and can conduct the home test > directly with CN, i.e. no home registration required. > > 2)All further BU/BA signaling is done directly with CN according to > RFC 4866. > > 3)All further signaling with HA is simply omitted. Thanks for the description. It makes sense and is compelling. Would this method mean that when MN moves some packets from CN arriving at "home" are lost until MN signals its new position to CN? Would this fail when CN is mobile? (CN changes its address). Would this require to modify all the CNs to which this MN may talk? Would this imply that this solution is to be applied in a small system (smaller than the size of the Internet), system within which other link-layer mobility protocols do fine (GGSN-SGSN) where the IP address is kept stable). This helps deriving requirements for it. > Our proposal builds on “enhanced route optimization” (RFC 4866), > which provides a nice security solution for R/O and creates the > ground for HA-free operation. There are more grounds for HA-less operation than just RFC4866. One can realize HA-less mobility operation without using RFC4866. > Little changes are required: e.g. MN must be able to deregister its > HoA at CN, etc. I agree, MN must be modified but I suppose CN too. Alex > > Regards, > > Georg > > ------------------------------------------------------------------------ > > *From:*Laganier, Julien [mailto:julienl@qualcomm.com] *Sent:* > Thursday, January 20, 2011 4:27 PM *To:* Hampel, K Georg (K Georg); > mext@ietf.org *Cc:* Klein, Thierry E (Thierry) *Subject:* RE: Support > of route optimization in *absence* of HA > > Georg, > > Is it correct that functionally your proposal is similar to Homeless > Mobile IPv6: > > http://tools.ietf.org/html/draft-nikander-mobileip-homelessv6-01 > > Best, > > --julien > > *From:*mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] *On > Behalf Of *Hampel, K Georg (K Georg) *Sent:* Thursday, January 20, > 2011 12:07 PM *To:* mext@ietf.org *Cc:* Hampel, K Georg (K Georg); > Klein, Thierry E (Thierry) *Subject:* [MEXT] Support of route > optimization in *absence* of HA > > All, > > We would like to add a proposal to MEXT that permits the mobile to > engage into route-optimization in *absence* of a home agent. > > Such a feature adds robustness to route optimization in case the HA > is temporarily unavailable. Under some circumstances, route > optimization *without* HA may be beneficial for performance reasons. > Our proposal requires “enhanced route optimization for Mobile IPv6” > (RFC 4866) as pre-requisite. > > We would like to obtain some feedback from the MEXT community via > this mailing list before we submit the proposal as a draft to the > workgroup. For this purpose, we have enclosed a high-level outline > below. Thanks. > > Regards, > > Georg Hampel > > Networking & Networks Domain > > BellLaboratories > > Alcatel-Lucent > > ============================================ > > Proposal: Support of Route-Optimization in Absence of Home Agent > > ABSTRACT: > > The proposal allows the mobile to engage into route optimization > (R/O) in *absence* of a HA. This feature increases robustness when > the HA becomes temporarily unavailable. Under some circumstances, R/O > *without* HA may be beneficial for performance reasons. This proposal > requires “enhanced route optimization for Mobile IPv6” (RFC 4866) as > pre-requisite. > > MOTIVATION: > > In route optimization (R/O), traffic packets are directly exchanged > between hosts without passing the HA. The mobile, however, still has > to interact with the HA. The HA provides (1) location service, (2) a > fallback path in case the direct path breaks, (3) a fallback in case > the correspondent does not support the protocol and (4) security > support for R/O-related signaling (i.e. home test). These functions > come at the following cost: > > ·Handovers may fail when the link to the HA or the HA itself are down > or congested. Mobility is not supported, when the mobile does not > have a HA. > > ·When the mobile starts a session outside of its home network, it > must use a HoA pertaining to its home network even if it engages into > R/O. This requirement adds air-interface overhead due to mobility > headers and processing overhead on the mobile. This upfront cost > incurs even if the mobile does not move during the session. > > ·Signaling handshakes have to be conducted between mobile and HA at > every mobility event. > > Currently, the Mobile IPv6 standard family forces the mobile to bear > these disadvantages in R/O even if the HA functions are not needed. > This specifically applies to scenarios where: > > ·Traffic is based on mobile-initiated requests to public servers > (majority of present mobile internet traffic). The HA’s location > service is not needed for such traffic. Location service may also be > provided by other means such as Dynamic DNS or on application layer > (e.g. SIP registrar). > > ·The fallback path through the HA has little value when it shares the > weakest link with the direct path. Since the weakest link is > typically the wireless link, this situation applies to all scenarios > where only one air interface is available (this is the typical case > rather than the exception). > > ·The mobile may know about the correspondent’s Mobile-IPv6 support > from prior sessions or through means external to the standard. > > ·The mobile applies the CGA-based procedure of RFC 4866, which makes > the HA’s security support for R/O unnecessary. This applies to all > cases where stateless addressing is permitted. > > To increase the flexibility and robustness of route-optimized Mobile > IPv6, we propose to make the HA an *optional* rather than a > *mandatory* feature, i.e. to permit operation without HA. This > proposal requires some additional extensions to the present > standard. > > HIGH-LEVEL OUTLINE > > The extensions build on Enhanced Route Optimization for Mobile IPv6 > (RFC 4866) to guarantee sufficient signaling security. With the > absence of a HA, mobility support in R/O can be provided in the > following manner: > > ·The mobile starts the traffic session from any of its currently > supported IP addresses. The selected IP address automatically takes > the function of the HoA for this session. This has the advantage that > conventional transport is used as long as the mobile does not move, > i.e. mobility headers and CoA-vs-HoA mapping is not needed. The HoA > must have been generated via CGA in compliance with RFC 4866. > > ·The mobile must conduct a “home-test” from this HoA in compliance > with RFC 4866. It may conduct the home-test prior to session > establishment, e.g. to find out if the correspondent supports the > standard. > > ·All binding update handshakes are conducted on the direct path > according to RFC 4866. > > ·Since sessions are always started from a currently supported IP > address, temporally overlapping sessions may use different HoAs. A > multi-homed mobile may also decide to start sessions from different > simultaneously supported IP addresses. There is no principle problem > here. > > ·Opposed to RFC 4866, the mobile need not perform the CoA > registration with the HA. > > ·The mobile must be able to deregister the HoA at the correspondent > in case the HoA is not supported anymore. This ensures that the > correspondent does not send packets to the HoA. After deregistration > of the HoA, the HoA is still used by higher protocol layers of > ongoing sessions. It must still be included in the mobility headers > for these sessions. > > ·When the mobile has HA support and the HA becomes temporarily > unavailable, the mobile simply continues R/O without HA as outlined > in the prior points. > > ·The mobile can publish its IP address in any location service. This > allows other hosts to initiate sessions with the mobile. These > sessions enjoy route-optimized mobility support only if the published > IP address was generated via CGA in compliance with RFC 4866. > > OPEN ISSUES > > These extensions have to be made compliant with RFC 5648 (multiple > CoA registration), RFC 3963 (NEMO) and others. More discussions are > necessary. > > > > _______________________________________________ MEXT mailing list > MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From georg.hampel@alcatel-lucent.com Fri Jan 21 08:13:39 2011 Return-Path: <georg.hampel@alcatel-lucent.com> X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 006743A6A40 for <mext@core3.amsl.com>; Fri, 21 Jan 2011 08:13:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OvrU16pOndqK for <mext@core3.amsl.com>; Fri, 21 Jan 2011 08:13:37 -0800 (PST) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by core3.amsl.com (Postfix) with ESMTP id 3392B3A6A3F for <mext@ietf.org>; Fri, 21 Jan 2011 08:13:35 -0800 (PST) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id p0LGGKG0014669 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 21 Jan 2011 10:16:20 -0600 (CST) Received: from USNAVSXCHHUB02.ndc.alcatel-lucent.com (usnavsxchhub02.ndc.alcatel-lucent.com [135.3.39.111]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p0LGGKw2019130 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 21 Jan 2011 10:16:20 -0600 Received: from USNAVSXCHMBSA2.ndc.alcatel-lucent.com ([135.3.39.127]) by USNAVSXCHHUB02.ndc.alcatel-lucent.com ([135.3.39.111]) with mapi; Fri, 21 Jan 2011 10:16:20 -0600 From: "Hampel, K Georg (K Georg)" <georg.hampel@alcatel-lucent.com> To: Arnaud Ebalard <arno@natisbad.org>, "mext@ietf.org" <mext@ietf.org> Date: Fri, 21 Jan 2011 10:16:18 -0600 Thread-Topic: [MEXT] reduce mobility header size Thread-Index: Acu5Qnn+9dPaMpYBS8GtIoosYVfgMQAQSv2w Message-ID: <154773479ED2314980CB638A48FC44348334D144@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> References: <154773479ED2314980CB638A48FC44348334CFA2@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <87d3nq3cp9.fsf@natisbad.org> In-Reply-To: <87d3nq3cp9.fsf@natisbad.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Subject: Re: [MEXT] reduce mobility header size X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG <mext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/mext> List-Post: <mailto:mext@ietf.org> List-Help: <mailto:mext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 21 Jan 2011 16:13:39 -0000 Hi, To clarify my prior question: I'm referring to the size of RH2 and HOA head= ers that are carried on traffic packets during route optimization when MN d= oes not reside in its home network. I agree with Arnaud's comment that RH2 and HOA can be dropped when peers su= stain an IPsec-protected traffic connection. May concern are traffic connections WITHOUT IPsec protection. This applies = to the vast majority of mobile internet traffic. The additional 24B (or 48B= if both peers are mobile) for RH2 and/or HOA represent a burden on wireles= s connections. In principle, the IP addresses carried in these headers coul= d be replaced by a hash or a session identifier. This, of course, creates m= iddle-box traversal issues. Has this issue been worked somewhere?=20 Thanks. Georg Hampel =20 -----Original Message----- From: Arnaud Ebalard [mailto:arno@natisbad.org]=20 Sent: Friday, January 21, 2011 3:04 AM To: Hampel, K Georg (K Georg) Cc: mext@ietf.org; Klein, Thierry E (Thierry) Subject: Re: [MEXT] reduce mobility header size Hi, "Hampel, K Georg (K Georg)" <georg.hampel@alcatel-lucent.com> writes: > Is there currently any effort to reduce the mobility header size in > route optimization? Thanks. Do you mean the presence of RH2 and HAO in DestOpt in the packets? If you intend *to use IPsec/IKE between the peers*, I proposed a solution to remove RH2 and HAO in DestOpt from packets and also the need for HoTI/HoT in the following draft:=20 http://tools.ietf.org/html/draft-ebalard-mext-ipsec-ro-02 For a simple introduction (description, advantages, drawbacks),=20 http://natisbad.org/IRO/ Cheers, a+ From georg.hampel@alcatel-lucent.com Fri Jan 21 08:47:27 2011 Return-Path: <georg.hampel@alcatel-lucent.com> X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 47A823A6A5A for <mext@core3.amsl.com>; Fri, 21 Jan 2011 08:47:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FWlq14JNuzr8 for <mext@core3.amsl.com>; Fri, 21 Jan 2011 08:47:25 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id AFC4F3A6A59 for <mext@ietf.org>; Fri, 21 Jan 2011 08:47:25 -0800 (PST) Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id p0LGo83I001465 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 21 Jan 2011 10:50:08 -0600 (CST) Received: from USNAVSXCHHUB01.ndc.alcatel-lucent.com (usnavsxchhub01.ndc.alcatel-lucent.com [135.3.39.110]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p0LGo8tY012066 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 21 Jan 2011 10:50:08 -0600 Received: from USNAVSXCHMBSA2.ndc.alcatel-lucent.com ([135.3.39.127]) by USNAVSXCHHUB01.ndc.alcatel-lucent.com ([135.3.39.110]) with mapi; Fri, 21 Jan 2011 10:50:08 -0600 From: "Hampel, K Georg (K Georg)" <georg.hampel@alcatel-lucent.com> To: Alexandru Petrescu <alexandru.petrescu@gmail.com>, "mext@ietf.org" <mext@ietf.org> Date: Fri, 21 Jan 2011 10:50:06 -0600 Thread-Topic: [MEXT] Support of route optimization in *absence* of HA Thread-Index: Acu5fwDLttG1aiVlQLmaNiMO5yRu1gACCvKA Message-ID: <154773479ED2314980CB638A48FC44348334D181@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> References: <154773479ED2314980CB638A48FC44348334CE4F@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <98A16B2D00B5724F81E80EF1927A0297036BB6@nasanexd01e.na.qualcomm.com> <154773479ED2314980CB638A48FC44348334CFA1@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <4D39A4A6.5030903@gmail.com> In-Reply-To: <4D39A4A6.5030903@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10 Subject: Re: [MEXT] Support of route optimization in *absence* of HA X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG <mext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/mext> List-Post: <mailto:mext@ietf.org> List-Help: <mailto:mext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 21 Jan 2011 16:47:27 -0000 Hi Alex, Thanks for your comments. I have inserted answers below. Upfront: RFC 4866 provides a convincing security solution to the return rou= tability test WITHOUT requiring a trust-relationship between peers. Note th= at it abolishes the need for a home-test during mobility events. This elimi= nates the reliance on the HA. In my opinion, the easiest way to introduce HA-free operation is via RFC 48= 66. The only pre-requisite of this RFC is stateless addressing. Does this p= ose any problem? Georg -----Original Message----- From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of Ale= xandru Petrescu Sent: Friday, January 21, 2011 10:22 AM To: mext@ietf.org Subject: Re: [MEXT] Support of route optimization in *absence* of HA Le 21/01/2011 02:24, Hampel, K Georg (K Georg) a =E9crit : > Julien, > > The intentions of Homeless MIPv6 are similar to those of our > proposal. > > In contrast to Homeless MIPv6, our proposal requires only minimal > upgrades to the present standard and implementation. (Homeless MIPv6 > requires changes to the TCP/UDP and requires AH, for instance). > > Here's the core idea of HA-free R/O: > > 1)When starting a session, the MN self-declares its current IP > address as the "HoA" for this session. This automatically means that > it resides in its "home network" and can conduct the home test > directly with CN, i.e. no home registration required. > > 2)All further BU/BA signaling is done directly with CN according to > RFC 4866. > > 3)All further signaling with HA is simply omitted. Thanks for the description. It makes sense and is compelling. Would this method mean that when MN moves some packets from CN arriving at "home" are lost until MN signals its new position to CN? [GH] RFC 4866 introduces exchange of credit-based traffic before the return= routability test has been finished. The handover performance should be bet= ter than for RFC3775-based R/O.=20 Would this fail when CN is mobile? (CN changes its address). [GH] No. The only problem occurs when both, MN and CN, move at the same tim= e. That's the price you pay in the absence of a HA. It may be overcome in c= ase one of the peers is multi-homed. Would this require to modify all the CNs to which this MN may talk? [GH] R/O always requires that CNs support MIPv6 (and the corresponding exte= nsions). Would this imply that this solution is to be applied in a small system (smaller than the size of the Internet), system within which other link-layer mobility protocols do fine (GGSN-SGSN) where the IP address is kept stable). [GH] The solution should be generic, not restricted to small systems. Inter= operability with 3GPP-based standards remains to be discussed. From the out= side, a 3GPP network should look like a L2 solution where the MN holds a fi= xed IP address. This helps deriving requirements for it. > Our proposal builds on "enhanced route optimization" (RFC 4866), > which provides a nice security solution for R/O and creates the > ground for HA-free operation. There are more grounds for HA-less operation than just RFC4866. One can realize HA-less mobility operation without using RFC4866. [GH] Yes indeed. For that purpose, it is necessary to get rid of the home-t= est during handovers. The home-test serves security purposes. Therefore, on= e has to come up with an alternative security solution. What's so bad with = RFC 4866? > Little changes are required: e.g. MN must be able to deregister its > HoA at CN, etc. I agree, MN must be modified but I suppose CN too. [GH] CN has to be able to understand MN's HoA-deregistration message. Alex > > Regards, > > Georg > > ------------------------------------------------------------------------ > > *From:*Laganier, Julien [mailto:julienl@qualcomm.com] *Sent:* > Thursday, January 20, 2011 4:27 PM *To:* Hampel, K Georg (K Georg); > mext@ietf.org *Cc:* Klein, Thierry E (Thierry) *Subject:* RE: Support > of route optimization in *absence* of HA > > Georg, > > Is it correct that functionally your proposal is similar to Homeless > Mobile IPv6: > > http://tools.ietf.org/html/draft-nikander-mobileip-homelessv6-01 > > Best, > > --julien > > *From:*mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] *On > Behalf Of *Hampel, K Georg (K Georg) *Sent:* Thursday, January 20, > 2011 12:07 PM *To:* mext@ietf.org *Cc:* Hampel, K Georg (K Georg); > Klein, Thierry E (Thierry) *Subject:* [MEXT] Support of route > optimization in *absence* of HA > > All, > > We would like to add a proposal to MEXT that permits the mobile to > engage into route-optimization in *absence* of a home agent. > > Such a feature adds robustness to route optimization in case the HA > is temporarily unavailable. Under some circumstances, route > optimization *without* HA may be beneficial for performance reasons. > Our proposal requires "enhanced route optimization for Mobile IPv6" > (RFC 4866) as pre-requisite. > > We would like to obtain some feedback from the MEXT community via > this mailing list before we submit the proposal as a draft to the > workgroup. For this purpose, we have enclosed a high-level outline > below. Thanks. > > Regards, > > Georg Hampel > > Networking & Networks Domain > > BellLaboratories > > Alcatel-Lucent > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > Proposal: Support of Route-Optimization in Absence of Home Agent > > ABSTRACT: > > The proposal allows the mobile to engage into route optimization > (R/O) in *absence* of a HA. This feature increases robustness when > the HA becomes temporarily unavailable. Under some circumstances, R/O > *without* HA may be beneficial for performance reasons. This proposal > requires "enhanced route optimization for Mobile IPv6" (RFC 4866) as > pre-requisite. > > MOTIVATION: > > In route optimization (R/O), traffic packets are directly exchanged > between hosts without passing the HA. The mobile, however, still has > to interact with the HA. The HA provides (1) location service, (2) a > fallback path in case the direct path breaks, (3) a fallback in case > the correspondent does not support the protocol and (4) security > support for R/O-related signaling (i.e. home test). These functions > come at the following cost: > > =B7Handovers may fail when the link to the HA or the HA itself are down > or congested. Mobility is not supported, when the mobile does not > have a HA. > > =B7When the mobile starts a session outside of its home network, it > must use a HoA pertaining to its home network even if it engages into > R/O. This requirement adds air-interface overhead due to mobility > headers and processing overhead on the mobile. This upfront cost > incurs even if the mobile does not move during the session. > > =B7Signaling handshakes have to be conducted between mobile and HA at > every mobility event. > > Currently, the Mobile IPv6 standard family forces the mobile to bear > these disadvantages in R/O even if the HA functions are not needed. > This specifically applies to scenarios where: > > =B7Traffic is based on mobile-initiated requests to public servers > (majority of present mobile internet traffic). The HA's location > service is not needed for such traffic. Location service may also be > provided by other means such as Dynamic DNS or on application layer > (e.g. SIP registrar). > > =B7The fallback path through the HA has little value when it shares the > weakest link with the direct path. Since the weakest link is > typically the wireless link, this situation applies to all scenarios > where only one air interface is available (this is the typical case > rather than the exception). > > =B7The mobile may know about the correspondent's Mobile-IPv6 support > from prior sessions or through means external to the standard. > > =B7The mobile applies the CGA-based procedure of RFC 4866, which makes > the HA's security support for R/O unnecessary. This applies to all > cases where stateless addressing is permitted. > > To increase the flexibility and robustness of route-optimized Mobile > IPv6, we propose to make the HA an *optional* rather than a > *mandatory* feature, i.e. to permit operation without HA. This > proposal requires some additional extensions to the present > standard. > > HIGH-LEVEL OUTLINE > > The extensions build on Enhanced Route Optimization for Mobile IPv6 > (RFC 4866) to guarantee sufficient signaling security. With the > absence of a HA, mobility support in R/O can be provided in the > following manner: > > =B7The mobile starts the traffic session from any of its currently > supported IP addresses. The selected IP address automatically takes > the function of the HoA for this session. This has the advantage that > conventional transport is used as long as the mobile does not move, > i.e. mobility headers and CoA-vs-HoA mapping is not needed. The HoA > must have been generated via CGA in compliance with RFC 4866. > > =B7The mobile must conduct a "home-test" from this HoA in compliance > with RFC 4866. It may conduct the home-test prior to session > establishment, e.g. to find out if the correspondent supports the > standard. > > =B7All binding update handshakes are conducted on the direct path > according to RFC 4866. > > =B7Since sessions are always started from a currently supported IP > address, temporally overlapping sessions may use different HoAs. A > multi-homed mobile may also decide to start sessions from different > simultaneously supported IP addresses. There is no principle problem > here. > > =B7Opposed to RFC 4866, the mobile need not perform the CoA > registration with the HA. > > =B7The mobile must be able to deregister the HoA at the correspondent > in case the HoA is not supported anymore. This ensures that the > correspondent does not send packets to the HoA. After deregistration > of the HoA, the HoA is still used by higher protocol layers of > ongoing sessions. It must still be included in the mobility headers > for these sessions. > > =B7When the mobile has HA support and the HA becomes temporarily > unavailable, the mobile simply continues R/O without HA as outlined > in the prior points. > > =B7The mobile can publish its IP address in any location service. This > allows other hosts to initiate sessions with the mobile. These > sessions enjoy route-optimized mobility support only if the published > IP address was generated via CGA in compliance with RFC 4866. > > OPEN ISSUES > > These extensions have to be made compliant with RFC 5648 (multiple > CoA registration), RFC 3963 (NEMO) and others. More discussions are > necessary. > > > > _______________________________________________ MEXT mailing list > MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From alexandru.petrescu@gmail.com Fri Jan 21 09:53:46 2011 Return-Path: <alexandru.petrescu@gmail.com> X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 38F493A6A66 for <mext@core3.amsl.com>; Fri, 21 Jan 2011 09:53:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zjX1prKxNolj for <mext@core3.amsl.com>; Fri, 21 Jan 2011 09:53:44 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.1]) by core3.amsl.com (Postfix) with ESMTP id D170E3A6A69 for <mext@ietf.org>; Fri, 21 Jan 2011 09:53:43 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id p0LHuKFV003874 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 21 Jan 2011 18:56:20 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id p0LHuJ9k001603; Fri, 21 Jan 2011 18:56:20 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [132.166.133.173] (is010173.intra.cea.fr [132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id p0LHuJRQ007668; Fri, 21 Jan 2011 18:56:19 +0100 Message-ID: <4D39C8C3.6050406@gmail.com> Date: Fri, 21 Jan 2011 18:56:19 +0100 From: Alexandru Petrescu <alexandru.petrescu@gmail.com> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "Hampel, K Georg (K Georg)" <georg.hampel@alcatel-lucent.com> References: <154773479ED2314980CB638A48FC44348334CE4F@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <98A16B2D00B5724F81E80EF1927A0297036BB6@nasanexd01e.na.qualcomm.com> <154773479ED2314980CB638A48FC44348334CFA1@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <4D39A4A6.5030903@gmail.com> <154773479ED2314980CB638A48FC44348334D181@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> In-Reply-To: <154773479ED2314980CB638A48FC44348334D181@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "mext@ietf.org" <mext@ietf.org> Subject: Re: [MEXT] Support of route optimization in *absence* of HA X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG <mext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/mext> List-Post: <mailto:mext@ietf.org> List-Help: <mailto:mext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 21 Jan 2011 17:53:46 -0000 Le 21/01/2011 17:50, Hampel, K Georg (K Georg) a écrit : > Hi Alex, > > Thanks for your comments. I have inserted answers below. > > Upfront: RFC 4866 provides a convincing security solution to the > return routability test WITHOUT requiring a trust-relationship > between peers. Note that it abolishes the need for a home-test > during mobility events. This eliminates the reliance on the HA. Ok, so the use of rfc4866 has the good side effect of eliminating the need of HA. If the goal is to extend rfc4866 then we're fine. But if the goal is to do HA-less Route Optimization, then I think there exist more possibilities than RFC4866. > In my opinion, the easiest way to introduce HA-free operation is via > RFC 4866. The only pre-requisite of this RFC is stateless > addressing. Does this pose any problem? No, no problem, I am trying to udnerstand what is one trying to do. That is the easiest way for you. For me, the easieest way to introduce HA-free operation is via MR-to-MR communication, secured at link layer. > -----Original Message----- From: mext-bounces@ietf.org > [mailto:mext-bounces@ietf.org] On Behalf Of Alexandru Petrescu Sent: > Friday, January 21, 2011 10:22 AM To: mext@ietf.org Subject: Re: > [MEXT] Support of route optimization in *absence* of HA > > Le 21/01/2011 02:24, Hampel, K Georg (K Georg) a écrit : >> Julien, >> >> The intentions of Homeless MIPv6 are similar to those of our >> proposal. >> >> In contrast to Homeless MIPv6, our proposal requires only minimal >> upgrades to the present standard and implementation. (Homeless >> MIPv6 requires changes to the TCP/UDP and requires AH, for >> instance). >> >> Here's the core idea of HA-free R/O: >> >> 1)When starting a session, the MN self-declares its current IP >> address as the "HoA" for this session. This automatically means >> that it resides in its "home network" and can conduct the home test >> directly with CN, i.e. no home registration required. >> >> 2)All further BU/BA signaling is done directly with CN according to >> RFC 4866. >> >> 3)All further signaling with HA is simply omitted. > > Thanks for the description. It makes sense and is compelling. > > Would this method mean that when MN moves some packets from CN > arriving at "home" are lost until MN signals its new position to CN? > [GH] RFC 4866 introduces exchange of credit-based traffic before > the return routability test has been finished. The handover > performance should be better than for RFC3775-based R/O. Hmm, I doubt this would add any noticeable improving effect in the overall handover performance. The performance hog during IPv6 handovers is not Mobile IPv6 but link layer (WiFi assoc req/resp, 3G connection setup) and address auto-configuration (RS/RA). The improvements of a better RR would probably be indeed improvements, but by how much? I doubt there'd be any noticeable effect on apps. > Would this fail when CN is mobile? (CN changes its address). [GH] > No. The only problem occurs when both, MN and CN, move at the same > time. That's the price you pay in the absence of a HA. It may be > overcome in case one of the peers is multi-homed. > > > Would this require to modify all the CNs to which this MN may talk? > [GH] R/O always requires that CNs support MIPv6 (and the > corresponding extensions). YEs, but a better rfc4866 would require to modify even a RFC3775-CN. Alex > Would this imply that this solution is to be applied in a small > system (smaller than the size of the Internet), system within which > other link-layer mobility protocols do fine (GGSN-SGSN) where the IP > address is kept stable). [GH] The solution should be generic, not > restricted to small systems. Interoperability with 3GPP-based > standards remains to be discussed. From the outside, a 3GPP network > should look like a L2 solution where the MN holds a fixed IP > address. > > This helps deriving requirements for it. > >> Our proposal builds on "enhanced route optimization" (RFC 4866), >> which provides a nice security solution for R/O and creates the >> ground for HA-free operation. > > There are more grounds for HA-less operation than just RFC4866. One > can realize HA-less mobility operation without using RFC4866. [GH] > Yes indeed. For that purpose, it is necessary to get rid of the > home-test during handovers. The home-test serves security purposes. > Therefore, one has to come up with an alternative security solution. > What's so bad with RFC 4866? > >> Little changes are required: e.g. MN must be able to deregister its >> HoA at CN, etc. > > I agree, MN must be modified but I suppose CN too. [GH] CN has to be > able to understand MN's HoA-deregistration message. > > Alex > >> >> Regards, >> >> Georg >> >> ------------------------------------------------------------------------ >> >> >> >> *From:*Laganier, Julien [mailto:julienl@qualcomm.com] *Sent:* >> Thursday, January 20, 2011 4:27 PM *To:* Hampel, K Georg (K Georg); >> mext@ietf.org *Cc:* Klein, Thierry E (Thierry) *Subject:* RE: >> Support of route optimization in *absence* of HA >> >> Georg, >> >> Is it correct that functionally your proposal is similar to >> Homeless Mobile IPv6: >> >> http://tools.ietf.org/html/draft-nikander-mobileip-homelessv6-01 >> >> Best, >> >> --julien >> >> *From:*mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] *On >> Behalf Of *Hampel, K Georg (K Georg) *Sent:* Thursday, January 20, >> 2011 12:07 PM *To:* mext@ietf.org *Cc:* Hampel, K Georg (K Georg); >> Klein, Thierry E (Thierry) *Subject:* [MEXT] Support of route >> optimization in *absence* of HA >> >> All, >> >> We would like to add a proposal to MEXT that permits the mobile to >> engage into route-optimization in *absence* of a home agent. >> >> Such a feature adds robustness to route optimization in case the HA >> is temporarily unavailable. Under some circumstances, route >> optimization *without* HA may be beneficial for performance >> reasons. Our proposal requires "enhanced route optimization for >> Mobile IPv6" (RFC 4866) as pre-requisite. >> >> We would like to obtain some feedback from the MEXT community via >> this mailing list before we submit the proposal as a draft to the >> workgroup. For this purpose, we have enclosed a high-level outline >> below. Thanks. >> >> Regards, >> >> Georg Hampel >> >> Networking& Networks Domain >> >> BellLaboratories >> >> Alcatel-Lucent >> >> ============================================ >> >> Proposal: Support of Route-Optimization in Absence of Home Agent >> >> ABSTRACT: >> >> The proposal allows the mobile to engage into route optimization >> (R/O) in *absence* of a HA. This feature increases robustness when >> the HA becomes temporarily unavailable. Under some circumstances, >> R/O *without* HA may be beneficial for performance reasons. This >> proposal requires "enhanced route optimization for Mobile IPv6" >> (RFC 4866) as pre-requisite. >> >> MOTIVATION: >> >> In route optimization (R/O), traffic packets are directly exchanged >> between hosts without passing the HA. The mobile, however, still >> has to interact with the HA. The HA provides (1) location service, >> (2) a fallback path in case the direct path breaks, (3) a fallback >> in case the correspondent does not support the protocol and (4) >> security support for R/O-related signaling (i.e. home test). These >> functions come at the following cost: >> >> ·Handovers may fail when the link to the HA or the HA itself are >> down or congested. Mobility is not supported, when the mobile does >> not have a HA. >> >> ·When the mobile starts a session outside of its home network, it >> must use a HoA pertaining to its home network even if it engages >> into R/O. This requirement adds air-interface overhead due to >> mobility headers and processing overhead on the mobile. This >> upfront cost incurs even if the mobile does not move during the >> session. >> >> ·Signaling handshakes have to be conducted between mobile and HA at >> every mobility event. >> >> Currently, the Mobile IPv6 standard family forces the mobile to >> bear these disadvantages in R/O even if the HA functions are not >> needed. This specifically applies to scenarios where: >> >> ·Traffic is based on mobile-initiated requests to public servers >> (majority of present mobile internet traffic). The HA's location >> service is not needed for such traffic. Location service may also >> be provided by other means such as Dynamic DNS or on application >> layer (e.g. SIP registrar). >> >> ·The fallback path through the HA has little value when it shares >> the weakest link with the direct path. Since the weakest link is >> typically the wireless link, this situation applies to all >> scenarios where only one air interface is available (this is the >> typical case rather than the exception). >> >> ·The mobile may know about the correspondent's Mobile-IPv6 support >> from prior sessions or through means external to the standard. >> >> ·The mobile applies the CGA-based procedure of RFC 4866, which >> makes the HA's security support for R/O unnecessary. This applies >> to all cases where stateless addressing is permitted. >> >> To increase the flexibility and robustness of route-optimized >> Mobile IPv6, we propose to make the HA an *optional* rather than a >> *mandatory* feature, i.e. to permit operation without HA. This >> proposal requires some additional extensions to the present >> standard. >> >> HIGH-LEVEL OUTLINE >> >> The extensions build on Enhanced Route Optimization for Mobile IPv6 >> (RFC 4866) to guarantee sufficient signaling security. With the >> absence of a HA, mobility support in R/O can be provided in the >> following manner: >> >> ·The mobile starts the traffic session from any of its currently >> supported IP addresses. The selected IP address automatically takes >> the function of the HoA for this session. This has the advantage >> that conventional transport is used as long as the mobile does not >> move, i.e. mobility headers and CoA-vs-HoA mapping is not needed. >> The HoA must have been generated via CGA in compliance with RFC >> 4866. >> >> ·The mobile must conduct a "home-test" from this HoA in compliance >> with RFC 4866. It may conduct the home-test prior to session >> establishment, e.g. to find out if the correspondent supports the >> standard. >> >> ·All binding update handshakes are conducted on the direct path >> according to RFC 4866. >> >> ·Since sessions are always started from a currently supported IP >> address, temporally overlapping sessions may use different HoAs. A >> multi-homed mobile may also decide to start sessions from >> different simultaneously supported IP addresses. There is no >> principle problem here. >> >> ·Opposed to RFC 4866, the mobile need not perform the CoA >> registration with the HA. >> >> ·The mobile must be able to deregister the HoA at the correspondent >> in case the HoA is not supported anymore. This ensures that the >> correspondent does not send packets to the HoA. After >> deregistration of the HoA, the HoA is still used by higher protocol >> layers of ongoing sessions. It must still be included in the >> mobility headers for these sessions. >> >> ·When the mobile has HA support and the HA becomes temporarily >> unavailable, the mobile simply continues R/O without HA as outlined >> in the prior points. >> >> ·The mobile can publish its IP address in any location service. >> This allows other hosts to initiate sessions with the mobile. These >> sessions enjoy route-optimized mobility support only if the >> published IP address was generated via CGA in compliance with RFC >> 4866. >> >> OPEN ISSUES >> >> These extensions have to be made compliant with RFC 5648 (multiple >> CoA registration), RFC 3963 (NEMO) and others. More discussions >> are necessary. >> >> >> >> _______________________________________________ MEXT mailing list >> MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext > > _______________________________________________ MEXT mailing list > MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext > From julienl@qualcomm.com Fri Jan 21 10:01:29 2011 Return-Path: <julienl@qualcomm.com> X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A58203A6A6F for <mext@core3.amsl.com>; Fri, 21 Jan 2011 10:01:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.306 X-Spam-Level: X-Spam-Status: No, score=-106.306 tagged_above=-999 required=5 tests=[AWL=0.292, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9GQqjBB2OaOK for <mext@core3.amsl.com>; Fri, 21 Jan 2011 10:01:28 -0800 (PST) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 9471B3A6A6E for <mext@ietf.org>; Fri, 21 Jan 2011 10:01:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1295633056; x=1327169056; h=from:to:cc:subject:thread-topic:thread-index:date: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: x-originating-ip:content-type:mime-version; z=From:=20"Laganier,=20Julien"=20<julienl@qualcomm.com> |To:=20"Hampel,=20K=20Georg=20(K=20Georg)"=20<georg.hampe l@alcatel-lucent.com>,=0D=0A=09"mext@ietf.org"=20<mext@ie tf.org>|CC:=20"Klein,=20Thierry=20E=20(Thierry)"=20<thier ry.klein@alcatel-lucent.com>|Subject:=20RE:=20reduce=20mo bility=20header=20size|Thread-Topic:=20reduce=20mobility =20header=20size|Thread-Index:=20Acu5CmJdbSxQl612R5mxNxDp v0tWngAixJew|Date:=20Fri,=2021=20Jan=202011=2018:03:23=20 +0000|Message-ID:=20<98A16B2D00B5724F81E80EF1927A029703A7 E6@nasanexd01e.na.qualcomm.com>|References:=20<154773479E D2314980CB638A48FC44348334CFA2@USNAVSXCHMBSA2.ndc.alcatel -lucent.com>|In-Reply-To:=20<154773479ED2314980CB638A48FC 44348334CFA2@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> |Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|x-originating-ip: =20[172.30.39.5]|Content-Type:=20multipart/alternative=3B =0D=0A=09boundary=3D"_000_98A16B2D00B5724F81E80EF1927A029 703A7E6nasanexd01enaqual_"|MIME-Version:=201.0; bh=rc38cbHPiKLAkK13gtG5+Mj+McvFoujOdVvE4ywMunY=; b=crqgL9aA2O9uPFxcoowKgELd37pmaj9uUgi1T/ejgbAbGL+ccMxawTd4 bfd5YQFMD0cKNT7/Dp8UEk8DJKC/e7md4WEkaGnc0zuTdt3qQnVTRB2kd KUK7D7M0C/Zf1mlFQSWeveuPfF/FxlPyzsY7oTWtRR60k2crcquE3/Glu I=; X-IronPort-AV: E=McAfee;i="5400,1158,6233"; a="71193293" Received: from ironmsg03-r.qualcomm.com ([172.30.46.17]) by wolverine02.qualcomm.com with ESMTP; 21 Jan 2011 10:04:16 -0800 X-IronPort-AV: E=Sophos;i="4.60,358,1291622400"; d="scan'208,217";a="43958569" Received: from nasanexhub03.na.qualcomm.com ([10.46.93.98]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/RC4-MD5; 21 Jan 2011 10:04:11 -0800 Received: from nasanexhc05.na.qualcomm.com (172.30.48.2) by nasanexhub03.na.qualcomm.com (10.46.93.98) with Microsoft SMTP Server (TLS) id 8.3.83.0; Fri, 21 Jan 2011 10:03:23 -0800 Received: from NASANEXD01E.na.qualcomm.com ([fe80::6555:8c37:4ee3:efc4]) by nasanexhc05.na.qualcomm.com ([::1]) with mapi id 14.01.0218.012; Fri, 21 Jan 2011 10:03:23 -0800 From: "Laganier, Julien" <julienl@qualcomm.com> To: "Hampel, K Georg (K Georg)" <georg.hampel@alcatel-lucent.com>, "mext@ietf.org" <mext@ietf.org> Thread-Topic: reduce mobility header size Thread-Index: Acu5CmJdbSxQl612R5mxNxDpv0tWngAixJew Date: Fri, 21 Jan 2011 18:03:23 +0000 Message-ID: <98A16B2D00B5724F81E80EF1927A029703A7E6@nasanexd01e.na.qualcomm.com> References: <154773479ED2314980CB638A48FC44348334CFA2@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> In-Reply-To: <154773479ED2314980CB638A48FC44348334CFA2@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.30.39.5] Content-Type: multipart/alternative; boundary="_000_98A16B2D00B5724F81E80EF1927A029703A7E6nasanexd01enaqual_" MIME-Version: 1.0 Cc: "Klein, Thierry E \(Thierry\)" <thierry.klein@alcatel-lucent.com> Subject: Re: [MEXT] reduce mobility header size X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG <mext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/mext> List-Post: <mailto:mext@ietf.org> List-Help: <mailto:mext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 21 Jan 2011 18:01:29 -0000 --_000_98A16B2D00B5724F81E80EF1927A029703A7E6nasanexd01enaqual_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable There was a draft: http://tools.ietf.org/html/draft-haddad-mip6-tunneling-optimization-01 --julien From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of Ham= pel, K Georg (K Georg) Sent: Thursday, January 20, 2011 5:28 PM To: mext@ietf.org Cc: Klein, Thierry E (Thierry) Subject: [MEXT] reduce mobility header size All, Is there currently any effort to reduce the mobility header size in route o= ptimization? Thanks. Georg Hampel --_000_98A16B2D00B5724F81E80EF1927A029703A7E6nasanexd01enaqual_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:= //www.w3.org/TR/REC-html40"> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"= > <meta name=3D"Generator" content=3D"Microsoft Word 12 (filtered medium)"> <style> <!-- /* Font Definitions */ @font-face {font-family:"MS Mincho"; panose-1:2 2 6 9 4 2 5 8 3 4;} @font-face {font-family:"MS Mincho"; panose-1:2 2 6 9 4 2 5 8 3 4;} @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} @font-face {font-family:Tahoma; panose-1:2 11 6 4 3 5 4 4 2 4;} @font-face {font-family:"\@MS Mincho"; panose-1:2 2 6 9 4 2 5 8 3 4;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0in; margin-bottom:.0001pt; font-size:10.0pt; font-family:"Times New Roman","serif";} a:link, span.MsoHyperlink {mso-style-priority:99; color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {mso-style-priority:99; color:purple; text-decoration:underline;} span.EmailStyle17 {mso-style-type:personal; font-family:"Arial","sans-serif"; color:windowtext;} span.EmailStyle18 {mso-style-type:personal-reply; font-family:"Calibri","sans-serif"; color:#1F497D;} .MsoChpDefault {mso-style-type:export-only; font-size:10.0pt;} @page Section1 {size:8.5in 11.0in; margin:1.0in 1.25in 1.0in 1.25in;} div.Section1 {page:Section1;} --> </style><!--[if gte mso 9]><xml> <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext=3D"edit"> <o:idmap v:ext=3D"edit" data=3D"1" /> </o:shapelayout></xml><![endif]--> </head> <body lang=3D"EN-US" link=3D"blue" vlink=3D"purple"> <div class=3D"Section1"> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif"; color:#1F497D">There was a draft:<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif"; color:#1F497D"><o:p> </o:p></span></p> <p class=3D"MsoNormal"><a href=3D"http://tools.ietf.org/html/draft-haddad-m= ip6-tunneling-optimization-01">http://tools.ietf.org/html/draft-haddad-mip6= -tunneling-optimization-01</a><o:p></o:p></p> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal">--julien<span style=3D"font-size:11.0pt;font-family:= "Calibri","sans-serif"; color:#1F497D"><o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif"; color:#1F497D"><o:p> </o:p></span></p> <div style=3D"border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in = 4.0pt"> <div> <div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in = 0in 0in"> <p class=3D"MsoNormal"><b><span style=3D"font-family:"Tahoma",&qu= ot;sans-serif"">From:</span></b><span style=3D"font-family:"Tahom= a","sans-serif""> mext-bounces@ietf.org [mailto:mext-bounces= @ietf.org] <b>On Behalf Of </b>Hampel, K Georg (K Georg)<br> <b>Sent:</b> Thursday, January 20, 2011 5:28 PM<br> <b>To:</b> mext@ietf.org<br> <b>Cc:</b> Klein, Thierry E (Thierry)<br> <b>Subject:</b> [MEXT] reduce mobility header size<o:p></o:p></span></p> </div> </div> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal"><span style=3D"font-family:"Arial","s= ans-serif"">All,<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-family:"Arial","s= ans-serif""><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-family:"Arial","s= ans-serif"">Is there currently any effort to reduce the mobility heade= r size in route optimization? Thanks.<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-family:"Arial","s= ans-serif""><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-family:"Arial","s= ans-serif"">Georg Hampel</span><o:p></o:p></p> <p class=3D"MsoNormal"><o:p> </o:p></p> </div> </div> </body> </html> --_000_98A16B2D00B5724F81E80EF1927A029703A7E6nasanexd01enaqual_-- From julienl@qualcomm.com Fri Jan 21 10:03:15 2011 Return-Path: <julienl@qualcomm.com> X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF74028C126 for <mext@core3.amsl.com>; Fri, 21 Jan 2011 10:03:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.322 X-Spam-Level: X-Spam-Status: No, score=-106.322 tagged_above=-999 required=5 tests=[AWL=0.276, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZlkVljO99pGN for <mext@core3.amsl.com>; Fri, 21 Jan 2011 10:03:05 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id EC9C33A6A6E for <mext@ietf.org>; Fri, 21 Jan 2011 10:03:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1295633151; x=1327169151; h=from:to:cc:subject:thread-topic:thread-index:date: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: x-cr-hashedpuzzle:x-cr-puzzleid:x-originating-ip: content-type:mime-version; z=From:=20"Laganier,=20Julien"=20<julienl@qualcomm.com> |To:=20"Hampel,=20K=20Georg=20(K=20Georg)"=20<georg.hampe l@alcatel-lucent.com>,=0D=0A=09"mext@ietf.org"=20<mext@ie tf.org>|CC:=20"Klein,=20Thierry=20E=20(Thierry)"=20<thier ry.klein@alcatel-lucent.com>|Subject:=20RE:=20Support=20o f=20route=20optimization=20in=20*absence*=20of=20HA |Thread-Topic:=20Support=20of=20route=20optimization=20in =20*absence*=20of=20HA|Thread-Index:=20Acu43ZmfXvNW17TRRj u54k2cv8RwfQACxVVwAAgzMeAAIwSxMA=3D=3D|Date:=20Fri,=2021 =20Jan=202011=2018:05:49=20+0000|Message-ID:=20<98A16B2D0 0B5724F81E80EF1927A029703A7F6@nasanexd01e.na.qualcomm.com >|References:=20<154773479ED2314980CB638A48FC44348334CE4F @USNAVSXCHMBSA2.ndc.alcatel-lucent.com>=0D=0A=20<98A16B2D 00B5724F81E80EF1927A0297036BB6@nasanexd01e.na.qualcomm.co m>=0D=0A=20<154773479ED2314980CB638A48FC44348334CFA1@USNA VSXCHMBSA2.ndc.alcatel-lucent.com>|In-Reply-To:=20<154773 479ED2314980CB638A48FC44348334CFA1@USNAVSXCHMBSA2.ndc.alc atel-lucent.com>|Accept-Language:=20en-US |Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|x-cr-hashedpuzzle:=20LXg=3D=20Gd88 =20I0cl=20Ka5v=20KdFj=20OPMN=20VoRj=20Wq1d=20YT/B=20ZB3f =20btJ7=0D=0A=20dsSG=20e+Pt=20hD9Q=20hGlL=0D=0A=20hiZf=3B 3=3BZwBlAG8AcgBnAC4AaABhAG0AcABlAGwAQABhAGwAYwBhAHQAZQBsA C0AbAB1AGMAZQBuAHQALgBjAG8AbQA7AG0AZQB4AHQAQABpAGUAdABmAC 4AbwByAGcAOwB0AGgAaQBlAHIAcgB5AC4AawBsAGUAaQBuAEAAYQBsAGM AYQB0AGUAbAAtAGwAdQBjAGUAbgB0AC4AYwBvAG0A=3BSosha1_v1=3B7 =3B{2D6B3C62-7F0F-4481-8B56-A86CA5EC7B06}=3BagB1AGwAaQBlA G4AbABAAHEAdQBhAGwAYwBvAG0AbQAuAGMAbwBtAA=3D=3D=3BFri,=0D =0A=2021=20Jan=202011=2018:05:43=0D=0A=20GMT=3BUgBFADoAIA BTAHUAcABwAG8AcgB0ACAAbwBmACAAcgBvAHUAdABlACAAbwBwAHQAaQB tAGkAegBhAHQAaQBvAG4AIABpAG4AIAAqAGEAYgBzAGUAbgBjAGUAKgAg AG8AZgAgAEgAQQA=3D|x-cr-puzzleid:=20{2D6B3C62-7F0F-4481-8 B56-A86CA5EC7B06}|x-originating-ip:=20[172.30.39.5] |Content-Type:=20multipart/alternative=3B=0D=0A=09boundar y=3D"_000_98A16B2D00B5724F81E80EF1927A029703A7F6nasanexd0 1enaqual_"|MIME-Version:=201.0; bh=aquRKhkovBVUOsVEYSfO/j4kSRVmbiITzAyfOm0UpWA=; b=qTj5BjYy1xc6owqmVqMn5MmBatULLqY3Df+Q1S9y2VbC3oxgLb7PShKK VfnNDwdXia0DSxUTwCnJh2LKEe0M7ESboMcMDai8QoItuN3aoYGYUiez6 QTimPw6PQ1EVSPlUC8dcld/RvQLf8eTolGUcWIVgVjispZKtYjHYopDO9 Q=; X-IronPort-AV: E=McAfee;i="5400,1158,6233"; a="71409883" Received: from ironmsg03-r.qualcomm.com ([172.30.46.17]) by wolverine01.qualcomm.com with ESMTP; 21 Jan 2011 10:05:51 -0800 X-IronPort-AV: E=Sophos;i="4.60,358,1291622400"; d="scan'208,217";a="43958815" Received: from nasanexhub02.na.qualcomm.com ([10.46.143.120]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/RC4-MD5; 21 Jan 2011 10:05:51 -0800 Received: from nasanexhc04.na.qualcomm.com (172.30.48.17) by nasanexhub02.na.qualcomm.com (10.46.143.120) with Microsoft SMTP Server (TLS) id 8.3.83.0; Fri, 21 Jan 2011 10:05:51 -0800 Received: from NASANEXD01E.na.qualcomm.com ([fe80::6555:8c37:4ee3:efc4]) by nasanexhc04.na.qualcomm.com ([::1]) with mapi id 14.01.0218.012; Fri, 21 Jan 2011 10:05:50 -0800 From: "Laganier, Julien" <julienl@qualcomm.com> To: "Hampel, K Georg (K Georg)" <georg.hampel@alcatel-lucent.com>, "mext@ietf.org" <mext@ietf.org> Thread-Topic: Support of route optimization in *absence* of HA Thread-Index: Acu43ZmfXvNW17TRRju54k2cv8RwfQACxVVwAAgzMeAAIwSxMA== Date: Fri, 21 Jan 2011 18:05:49 +0000 Message-ID: <98A16B2D00B5724F81E80EF1927A029703A7F6@nasanexd01e.na.qualcomm.com> References: <154773479ED2314980CB638A48FC44348334CE4F@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <98A16B2D00B5724F81E80EF1927A0297036BB6@nasanexd01e.na.qualcomm.com> <154773479ED2314980CB638A48FC44348334CFA1@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> In-Reply-To: <154773479ED2314980CB638A48FC44348334CFA1@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: LXg= Gd88 I0cl Ka5v KdFj OPMN VoRj Wq1d YT/B ZB3f btJ7 dsSG e+Pt hD9Q hGlL hiZf; 3; ZwBlAG8AcgBnAC4AaABhAG0AcABlAGwAQABhAGwAYwBhAHQAZQBsAC0AbAB1AGMAZQBuAHQALgBjAG8AbQA7AG0AZQB4AHQAQABpAGUAdABmAC4AbwByAGcAOwB0AGgAaQBlAHIAcgB5AC4AawBsAGUAaQBuAEAAYQBsAGMAYQB0AGUAbAAtAGwAdQBjAGUAbgB0AC4AYwBvAG0A; Sosha1_v1; 7; {2D6B3C62-7F0F-4481-8B56-A86CA5EC7B06}; agB1AGwAaQBlAG4AbABAAHEAdQBhAGwAYwBvAG0AbQAuAGMAbwBtAA==; Fri, 21 Jan 2011 18:05:43 GMT; UgBFADoAIABTAHUAcABwAG8AcgB0ACAAbwBmACAAcgBvAHUAdABlACAAbwBwAHQAaQBtAGkAegBhAHQAaQBvAG4AIABpAG4AIAAqAGEAYgBzAGUAbgBjAGUAKgAgAG8AZgAgAEgAQQA= x-cr-puzzleid: {2D6B3C62-7F0F-4481-8B56-A86CA5EC7B06} x-originating-ip: [172.30.39.5] Content-Type: multipart/alternative; boundary="_000_98A16B2D00B5724F81E80EF1927A029703A7F6nasanexd01enaqual_" MIME-Version: 1.0 Cc: "Klein, Thierry E \(Thierry\)" <thierry.klein@alcatel-lucent.com> Subject: Re: [MEXT] Support of route optimization in *absence* of HA X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG <mext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/mext> List-Post: <mailto:mext@ietf.org> List-Help: <mailto:mext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 21 Jan 2011 18:03:15 -0000 --_000_98A16B2D00B5724F81E80EF1927A029703A7F6nasanexd01enaqual_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Georg, Thanks for clarifying, this is what I thought. FWIW, I've tried to extend t= he RFC 4866 to secure bindings between the MN and the HA in http://tools.ie= tf.org/html/draft-laganier-mext-cga-01 --julien From: Hampel, K Georg (K Georg) [mailto:georg.hampel@alcatel-lucent.com] Sent: Thursday, January 20, 2011 5:25 PM To: Laganier, Julien; mext@ietf.org Cc: Klein, Thierry E (Thierry) Subject: RE: Support of route optimization in *absence* of HA Julien, The intentions of Homeless MIPv6 are similar to those of our proposal. In contrast to Homeless MIPv6, our proposal requires only minimal upgrades = to the present standard and implementation. (Homeless MIPv6 requires change= s to the TCP/UDP and requires AH, for instance). Here's the core idea of HA-free R/O: 1) When starting a session, the MN self-declares its current IP address as= the "HoA" for this session. This automatically means that it resides in it= s "home network" and can conduct the home test directly with CN, i.e. no ho= me registration required. 2) All further BU/BA signaling is done directly with CN according to RFC 4= 866. 3) All further signaling with HA is simply omitted. Our proposal builds on "enhanced route optimization" (RFC 4866), which prov= ides a nice security solution for R/O and creates the ground for HA-free op= eration. Little changes are required: e.g. MN must be able to deregister its HoA at = CN, etc. Regards, Georg ________________________________ From: Laganier, Julien [mailto:julienl@qualcomm.com] Sent: Thursday, January 20, 2011 4:27 PM To: Hampel, K Georg (K Georg); mext@ietf.org Cc: Klein, Thierry E (Thierry) Subject: RE: Support of route optimization in *absence* of HA Georg, Is it correct that functionally your proposal is similar to Homeless Mobile= IPv6: http://tools.ietf.org/html/draft-nikander-mobileip-homelessv6-01 Best, --julien From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of Ham= pel, K Georg (K Georg) Sent: Thursday, January 20, 2011 12:07 PM To: mext@ietf.org Cc: Hampel, K Georg (K Georg); Klein, Thierry E (Thierry) Subject: [MEXT] Support of route optimization in *absence* of HA All, We would like to add a proposal to MEXT that permits the mobile to engage i= nto route-optimization in *absence* of a home agent. Such a feature adds robustness to route optimization in case the HA is temp= orarily unavailable. Under some circumstances, route optimization *without*= HA may be beneficial for performance reasons. Our proposal requires "enhan= ced route optimization for Mobile IPv6" (RFC 4866) as pre-requisite. We would like to obtain some feedback from the MEXT community via this mail= ing list before we submit the proposal as a draft to the workgroup. For thi= s purpose, we have enclosed a high-level outline below. Thanks. Regards, Georg Hampel Networking & Networks Domain Bell Laboratories Alcatel-Lucent =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Proposal: Support of Route-Optimization in Absence of Home Agent ABSTRACT: The proposal allows the mobile to engage into route optimization (R/O) in *= absence* of a HA. This feature increases robustness when the HA becomes tem= porarily unavailable. Under some circumstances, R/O *without* HA may be ben= eficial for performance reasons. This proposal requires "enhanced route opt= imization for Mobile IPv6" (RFC 4866) as pre-requisite. MOTIVATION: In route optimization (R/O), traffic packets are directly exchanged between= hosts without passing the HA. The mobile, however, still has to interact w= ith the HA. The HA provides (1) location service, (2) a fallback path in ca= se the direct path breaks, (3) a fallback in case the correspondent does no= t support the protocol and (4) security support for R/O-related signaling (= i.e. home test). These functions come at the following cost: * Handovers may fail when the link to the HA or the HA itself are dow= n or congested. Mobility is not supported, when the mobile does not have a = HA. * When the mobile starts a session outside of its home network, it mu= st use a HoA pertaining to its home network even if it engages into R/O. Th= is requirement adds air-interface overhead due to mobility headers and proc= essing overhead on the mobile. This upfront cost incurs even if the mobile = does not move during the session. * Signaling handshakes have to be conducted between mobile and HA at = every mobility event. Currently, the Mobile IPv6 standard family forces the mobile to bear these = disadvantages in R/O even if the HA functions are not needed. This specific= ally applies to scenarios where: * Traffic is based on mobile-initiated requests to public servers (ma= jority of present mobile internet traffic). The HA's location service is no= t needed for such traffic. Location service may also be provided by other m= eans such as Dynamic DNS or on application layer (e.g. SIP registrar). * The fallback path through the HA has little value when it shares th= e weakest link with the direct path. Since the weakest link is typically th= e wireless link, this situation applies to all scenarios where only one air= interface is available (this is the typical case rather than the exception= ). * The mobile may know about the correspondent's Mobile-IPv6 support f= rom prior sessions or through means external to the standard. * The mobile applies the CGA-based procedure of RFC 4866, which makes= the HA's security support for R/O unnecessary. This applies to all cases w= here stateless addressing is permitted. To increase the flexibility and robustness of route-optimized Mobile IPv6, = we propose to make the HA an *optional* rather than a *mandatory* feature, = i.e. to permit operation without HA. This proposal requires some additional= extensions to the present standard. HIGH-LEVEL OUTLINE The extensions build on Enhanced Route Optimization for Mobile IPv6 (RFC 48= 66) to guarantee sufficient signaling security. With the absence of a HA, m= obility support in R/O can be provided in the following manner: * The mobile starts the traffic session from any of its currently sup= ported IP addresses. The selected IP address automatically takes the functi= on of the HoA for this session. This has the advantage that conventional tr= ansport is used as long as the mobile does not move, i.e. mobility headers = and CoA-vs-HoA mapping is not needed. The HoA must have been generated via = CGA in compliance with RFC 4866. * The mobile must conduct a "home-test" from this HoA in compliance w= ith RFC 4866. It may conduct the home-test prior to session establishment, = e.g. to find out if the correspondent supports the standard. * All binding update handshakes are conducted on the direct path acco= rding to RFC 4866. * Since sessions are always started from a currently supported IP add= ress, temporally overlapping sessions may use different HoAs. A multi-homed= mobile may also decide to start sessions from different simultaneously sup= ported IP addresses. There is no principle problem here. * Opposed to RFC 4866, the mobile need not perform the CoA registrati= on with the HA. * The mobile must be able to deregister the HoA at the correspondent = in case the HoA is not supported anymore. This ensures that the corresponde= nt does not send packets to the HoA. After deregistration of the HoA, the H= oA is still used by higher protocol layers of ongoing sessions. It must sti= ll be included in the mobility headers for these sessions. * When the mobile has HA support and the HA becomes temporarily unava= ilable, the mobile simply continues R/O without HA as outlined in the prior= points. * The mobile can publish its IP address in any location service. This= allows other hosts to initiate sessions with the mobile. These sessions en= joy route-optimized mobility support only if the published IP address was g= enerated via CGA in compliance with RFC 4866. OPEN ISSUES These extensions have to be made compliant with RFC 5648 (multiple CoA regi= stration), RFC 3963 (NEMO) and others. More discussions are necessary. --_000_98A16B2D00B5724F81E80EF1927A029703A7F6nasanexd01enaqual_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:x=3D"urn:schemas-microsoft-com:office:excel" xmlns:p=3D"urn:schemas-m= icrosoft-com:office:powerpoint" xmlns:a=3D"urn:schemas-microsoft-com:office= :access" xmlns:dt=3D"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s=3D"= uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs=3D"urn:schemas-microsof= t-com:rowset" xmlns:z=3D"#RowsetSchema" xmlns:b=3D"urn:schemas-microsoft-co= m:office:publisher" xmlns:ss=3D"urn:schemas-microsoft-com:office:spreadshee= t" xmlns:c=3D"urn:schemas-microsoft-com:office:component:spreadsheet" xmlns= :odc=3D"urn:schemas-microsoft-com:office:odc" xmlns:oa=3D"urn:schemas-micro= soft-com:office:activation" xmlns:html=3D"http://www.w3.org/TR/REC-html40" = xmlns:q=3D"http://schemas.xmlsoap.org/soap/envelope/" xmlns:rtc=3D"http://m= icrosoft.com/officenet/conferencing" xmlns:D=3D"DAV:" xmlns:Repl=3D"http://= schemas.microsoft.com/repl/" xmlns:mt=3D"http://schemas.microsoft.com/share= point/soap/meetings/" xmlns:x2=3D"http://schemas.microsoft.com/office/excel= /2003/xml" xmlns:ppda=3D"http://www.passport.com/NameSpace.xsd" xmlns:ois= =3D"http://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir=3D"http://= schemas.microsoft.com/sharepoint/soap/directory/" xmlns:ds=3D"http://www.w3= .org/2000/09/xmldsig#" xmlns:dsp=3D"http://schemas.microsoft.com/sharepoint= /dsp" xmlns:udc=3D"http://schemas.microsoft.com/data/udc" xmlns:xsd=3D"http= ://www.w3.org/2001/XMLSchema" xmlns:sub=3D"http://schemas.microsoft.com/sha= repoint/soap/2002/1/alerts/" xmlns:ec=3D"http://www.w3.org/2001/04/xmlenc#"= xmlns:sp=3D"http://schemas.microsoft.com/sharepoint/" xmlns:sps=3D"http://= schemas.microsoft.com/sharepoint/soap/" xmlns:xsi=3D"http://www.w3.org/2001= /XMLSchema-instance" xmlns:udcs=3D"http://schemas.microsoft.com/data/udc/so= ap" xmlns:udcxf=3D"http://schemas.microsoft.com/data/udc/xmlfile" xmlns:udc= p2p=3D"http://schemas.microsoft.com/data/udc/parttopart" xmlns:wf=3D"http:/= /schemas.microsoft.com/sharepoint/soap/workflow/" xmlns:dsss=3D"http://sche= mas.microsoft.com/office/2006/digsig-setup" xmlns:dssi=3D"http://schemas.mi= crosoft.com/office/2006/digsig" xmlns:mdssi=3D"http://schemas.openxmlformat= s.org/package/2006/digital-signature" xmlns:mver=3D"http://schemas.openxmlf= ormats.org/markup-compatibility/2006" xmlns:m=3D"http://schemas.microsoft.c= om/office/2004/12/omml" xmlns:mrels=3D"http://schemas.openxmlformats.org/pa= ckage/2006/relationships" xmlns:spwp=3D"http://microsoft.com/sharepoint/web= partpages" xmlns:ex12t=3D"http://schemas.microsoft.com/exchange/services/20= 06/types" xmlns:ex12m=3D"http://schemas.microsoft.com/exchange/services/200= 6/messages" xmlns:pptsl=3D"http://schemas.microsoft.com/sharepoint/soap/Sli= deLibrary/" xmlns:spsl=3D"http://microsoft.com/webservices/SharePointPortal= Server/PublishedLinksService" xmlns:Z=3D"urn:schemas-microsoft-com:" xmlns:= st=3D"" xmlns=3D"http://www.w3.org/TR/REC-html40"> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"= > <meta name=3D"Generator" content=3D"Microsoft Word 12 (filtered medium)"> <!--[if !mso]> <style> v\:* {behavior:url(#default#VML);} o\:* {behavior:url(#default#VML);} w\:* {behavior:url(#default#VML);} .shape {behavior:url(#default#VML);} </style> <![endif]--><style> <!-- /* Font Definitions */ @font-face {font-family:"MS Mincho"; panose-1:2 2 6 9 4 2 5 8 3 4;} @font-face {font-family:"MS Mincho"; panose-1:2 2 6 9 4 2 5 8 3 4;} @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} @font-face {font-family:Tahoma; panose-1:2 11 6 4 3 5 4 4 2 4;} @font-face {font-family:"\@MS Mincho"; panose-1:2 2 6 9 4 2 5 8 3 4;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0in; margin-bottom:.0001pt; font-size:10.0pt; font-family:"Times New Roman","serif";} a:link, span.MsoHyperlink {mso-style-priority:99; color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {mso-style-priority:99; color:purple; text-decoration:underline;} span.EmailStyle17 {mso-style-type:personal; font-family:"Arial","sans-serif"; color:windowtext;} span.EmailStyle18 {mso-style-type:personal; font-family:"Calibri","sans-serif"; color:#1F497D;} span.EmailStyle19 {mso-style-type:personal; font-family:"Arial","sans-serif"; color:navy;} span.EmailStyle20 {mso-style-type:personal-reply; font-family:"Calibri","sans-serif"; color:#1F497D;} .MsoChpDefault {mso-style-type:export-only; font-size:10.0pt;} @page Section1 {size:8.5in 11.0in; margin:1.0in 1.25in 1.0in 1.25in;} div.Section1 {page:Section1;} /* List Definitions */ @list l0 {mso-list-id:462961695; mso-list-type:hybrid; mso-list-template-ids:-2116359956 -727278766 67698691 67698693 67698689 67= 698691 67698693 67698689 67698691 67698693;} @list l0:level1 {mso-level-number-format:bullet; mso-level-text:\F0B7; mso-level-tab-stop:-5.0pt; mso-level-number-position:left; margin-left:14.0pt; text-indent:-14.0pt; mso-ansi-font-size:9.0pt; font-family:Symbol;} @list l0:level2 {mso-level-tab-stop:1.0in; mso-level-number-position:left; text-indent:-.25in;} @list l0:level3 {mso-level-tab-stop:1.5in; mso-level-number-position:left; text-indent:-.25in;} @list l0:level4 {mso-level-tab-stop:2.0in; mso-level-number-position:left; text-indent:-.25in;} @list l0:level5 {mso-level-tab-stop:2.5in; mso-level-number-position:left; text-indent:-.25in;} @list l0:level6 {mso-level-tab-stop:3.0in; mso-level-number-position:left; text-indent:-.25in;} @list l0:level7 {mso-level-tab-stop:3.5in; mso-level-number-position:left; text-indent:-.25in;} @list l0:level8 {mso-level-tab-stop:4.0in; mso-level-number-position:left; text-indent:-.25in;} @list l0:level9 {mso-level-tab-stop:4.5in; mso-level-number-position:left; text-indent:-.25in;} @list l1 {mso-list-id:823199790; mso-list-type:hybrid; mso-list-template-ids:-198536934 -727278766 67698691 67698693 67698689 676= 98691 67698693 67698689 67698691 67698693;} @list l1:level1 {mso-level-number-format:bullet; mso-level-text:\F0B7; mso-level-tab-stop:-5.0pt; mso-level-number-position:left; margin-left:14.0pt; text-indent:-14.0pt; mso-ansi-font-size:9.0pt; font-family:Symbol;} @list l1:level2 {mso-level-tab-stop:1.0in; mso-level-number-position:left; text-indent:-.25in;} @list l1:level3 {mso-level-tab-stop:1.5in; mso-level-number-position:left; text-indent:-.25in;} @list l1:level4 {mso-level-tab-stop:2.0in; mso-level-number-position:left; text-indent:-.25in;} @list l1:level5 {mso-level-tab-stop:2.5in; mso-level-number-position:left; text-indent:-.25in;} @list l1:level6 {mso-level-tab-stop:3.0in; mso-level-number-position:left; text-indent:-.25in;} @list l1:level7 {mso-level-tab-stop:3.5in; mso-level-number-position:left; text-indent:-.25in;} @list l1:level8 {mso-level-tab-stop:4.0in; mso-level-number-position:left; text-indent:-.25in;} @list l1:level9 {mso-level-tab-stop:4.5in; mso-level-number-position:left; text-indent:-.25in;} @list l2 {mso-list-id:1836452376; mso-list-type:hybrid; mso-list-template-ids:-1378300656 -1558151418 67698713 67698715 67698703 6= 7698713 67698715 67698703 67698713 67698715;} @list l2:level1 {mso-level-text:"%1\)"; mso-level-tab-stop:.5in; mso-level-number-position:left; text-indent:-.25in;} @list l2:level2 {mso-level-tab-stop:1.0in; mso-level-number-position:left; text-indent:-.25in;} @list l2:level3 {mso-level-tab-stop:1.5in; mso-level-number-position:left; text-indent:-.25in;} @list l2:level4 {mso-level-tab-stop:2.0in; mso-level-number-position:left; text-indent:-.25in;} @list l2:level5 {mso-level-tab-stop:2.5in; mso-level-number-position:left; text-indent:-.25in;} @list l2:level6 {mso-level-tab-stop:3.0in; mso-level-number-position:left; text-indent:-.25in;} @list l2:level7 {mso-level-tab-stop:3.5in; mso-level-number-position:left; text-indent:-.25in;} @list l2:level8 {mso-level-tab-stop:4.0in; mso-level-number-position:left; text-indent:-.25in;} @list l2:level9 {mso-level-tab-stop:4.5in; mso-level-number-position:left; text-indent:-.25in;} @list l3 {mso-list-id:2000302011; mso-list-type:hybrid; mso-list-template-ids:-1553676858 -727278766 67698691 67698693 67698689 67= 698691 67698693 67698689 67698691 67698693;} @list l3:level1 {mso-level-number-format:bullet; mso-level-text:\F0B7; mso-level-tab-stop:-5.0pt; mso-level-number-position:left; margin-left:14.0pt; text-indent:-14.0pt; mso-ansi-font-size:9.0pt; font-family:Symbol;} @list l3:level2 {mso-level-tab-stop:1.0in; mso-level-number-position:left; text-indent:-.25in;} @list l3:level3 {mso-level-tab-stop:1.5in; mso-level-number-position:left; text-indent:-.25in;} @list l3:level4 {mso-level-tab-stop:2.0in; mso-level-number-position:left; text-indent:-.25in;} @list l3:level5 {mso-level-tab-stop:2.5in; mso-level-number-position:left; text-indent:-.25in;} @list l3:level6 {mso-level-tab-stop:3.0in; mso-level-number-position:left; text-indent:-.25in;} @list l3:level7 {mso-level-tab-stop:3.5in; mso-level-number-position:left; text-indent:-.25in;} @list l3:level8 {mso-level-tab-stop:4.0in; mso-level-number-position:left; text-indent:-.25in;} @list l3:level9 {mso-level-tab-stop:4.5in; mso-level-number-position:left; text-indent:-.25in;} ol {margin-bottom:0in;} ul {margin-bottom:0in;} --> </style><!--[if gte mso 9]><xml> <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext=3D"edit"> <o:idmap v:ext=3D"edit" data=3D"1" /> </o:shapelayout></xml><![endif]--> </head> <body lang=3D"EN-US" link=3D"blue" vlink=3D"purple"> <div class=3D"Section1"> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif"; color:#1F497D">Georg,<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif"; color:#1F497D"><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif"; color:#1F497D">Thanks for clarifying, this is what I thought. FWIW, I’= ;ve tried to extend the RFC 4866 to secure bindings between the MN and the = HA in </span><a href=3D"http://tools.ietf.org/html/draft-laganier-mext-cga-01">ht= tp://tools.ietf.org/html/draft-laganier-mext-cga-01</a><o:p></o:p></p> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif"; color:#1F497D">--julien<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif"; color:#1F497D"><o:p> </o:p></span></p> <div style=3D"border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in = 4.0pt"> <div> <div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in = 0in 0in"> <p class=3D"MsoNormal"><b><span style=3D"font-family:"Tahoma",&qu= ot;sans-serif"">From:</span></b><span style=3D"font-family:"Tahom= a","sans-serif""> Hampel, K Georg (K Georg) [mailto:georg.ha= mpel@alcatel-lucent.com] <br> <b>Sent:</b> Thursday, January 20, 2011 5:25 PM<br> <b>To:</b> Laganier, Julien; mext@ietf.org<br> <b>Cc:</b> Klein, Thierry E (Thierry)<br> <b>Subject:</b> RE: Support of route optimization in *absence* of HA<o:p></= o:p></span></p> </div> </div> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal"><span lang=3D"EN" style=3D"font-family:"Arial&q= uot;,"sans-serif"; color:navy">Julien,<o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN" style=3D"font-family:"Arial&q= uot;,"sans-serif"; color:navy"><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN" style=3D"font-family:"Arial&q= uot;,"sans-serif"; color:navy">The intentions of Homeless MIPv6 are similar to those of our pr= oposal. <o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN" style=3D"font-family:"Arial&q= uot;,"sans-serif"; color:navy"><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN" style=3D"font-family:"Arial&q= uot;,"sans-serif"; color:navy">In contrast to Homeless MIPv6, our proposal requires only minim= al upgrades to the present standard and implementation. (Homeless MIPv6 req= uires changes to the TCP/UDP and requires AH, for instance).<o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN" style=3D"font-family:"Arial&q= uot;,"sans-serif"; color:navy"><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN" style=3D"font-family:"Arial&q= uot;,"sans-serif"; color:navy">Here’s the core idea of HA-free R/O: <o:p></o:p></span></p> <p class=3D"MsoNormal" style=3D"margin-left:.5in;text-indent:-.25in;mso-lis= t:l2 level1 lfo2"> <![if !supportLists]><span lang=3D"EN" style=3D"font-family:"Arial&quo= t;,"sans-serif";color:navy"><span style=3D"mso-list:Ignore">1)<sp= an style=3D"font:7.0pt "Times New Roman"">  </span></span></span><![endif]><span lang=3D"EN" style=3D"font-family:"= ;Arial","sans-serif";color:navy">When starting a session, th= e MN self-declares its current IP address as the “HoA” for this= session. This automatically means that it resides in its “home netwo= rk” and can conduct the home test directly with CN, i.e. no home registration = required.<o:p></o:p></span></p> <p class=3D"MsoNormal" style=3D"margin-left:.5in;text-indent:-.25in;mso-lis= t:l2 level1 lfo2"> <![if !supportLists]><span lang=3D"EN" style=3D"font-family:"Arial&quo= t;,"sans-serif";color:navy"><span style=3D"mso-list:Ignore">2)<sp= an style=3D"font:7.0pt "Times New Roman"">  </span></span></span><![endif]><span lang=3D"EN" style=3D"font-family:"= ;Arial","sans-serif";color:navy">All further BU/BA signaling= is done directly with CN according to RFC 4866.<o:p></o:p></span></p> <p class=3D"MsoNormal" style=3D"margin-left:.5in;text-indent:-.25in;mso-lis= t:l2 level1 lfo2"> <![if !supportLists]><span lang=3D"EN" style=3D"font-family:"Arial&quo= t;,"sans-serif";color:navy"><span style=3D"mso-list:Ignore">3)<sp= an style=3D"font:7.0pt "Times New Roman"">  </span></span></span><![endif]><span lang=3D"EN" style=3D"font-family:"= ;Arial","sans-serif";color:navy">All further signaling with = HA is simply omitted.<o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN" style=3D"font-family:"Arial&q= uot;,"sans-serif"; color:navy"><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN" style=3D"font-family:"Arial&q= uot;,"sans-serif"; color:navy">Our proposal builds on “enhanced route optimization”= ; (RFC 4866), which provides a nice security solution for R/O and creates t= he ground for HA-free operation.<o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN" style=3D"font-family:"Arial&q= uot;,"sans-serif"; color:navy">Little changes are required: e.g. MN must be able to deregister= its HoA at CN, etc.<o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN" style=3D"font-family:"Arial&q= uot;,"sans-serif"; color:navy"><o:p> </o:p></span></p> <div> <p class=3D"MsoNormal"><span lang=3D"EN" style=3D"font-family:"Arial&q= uot;,"sans-serif"; color:navy">Regards,<o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN" style=3D"font-family:"Arial&q= uot;,"sans-serif"; color:navy"><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN" style=3D"font-family:"Arial&q= uot;,"sans-serif"; color:navy">Georg<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"color:navy"><o:p> </o:p></span><= /p> </div> <div> <div class=3D"MsoNormal" align=3D"center" style=3D"text-align:center"><span= style=3D"font-size:12.0pt"> <hr size=3D"2" width=3D"100%" align=3D"center"> </span></div> <p class=3D"MsoNormal"><b><span style=3D"font-family:"Tahoma",&qu= ot;sans-serif"">From:</span></b><span style=3D"font-family:"Tahom= a","sans-serif""> Laganier, Julien [mailto:julienl@qualcomm.= com] <br> <b>Sent:</b> Thursday, January 20, 2011 4:27 PM<br> <b>To:</b> Hampel, K Georg (K Georg); mext@ietf.org<br> <b>Cc:</b> Klein, Thierry E (Thierry)<br> <b>Subject:</b> RE: Support of route optimization in *absence* of HA</span>= <span style=3D"font-size:12.0pt"><o:p></o:p></span></p> </div> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif"; color:#1F497D">Georg,<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif"; color:#1F497D"><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif"; color:#1F497D">Is it correct that functionally your proposal is similar to = Homeless Mobile IPv6:<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif"; color:#1F497D"><o:p> </o:p></span></p> <p class=3D"MsoNormal"><a href=3D"http://tools.ietf.org/html/draft-nikander= -mobileip-homelessv6-01">http://tools.ietf.org/html/draft-nikander-mobileip= -homelessv6-01</a><o:p></o:p></p> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif"; color:#1F497D">Best,<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif"; color:#1F497D"><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif"; color:#1F497D">--julien<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif"; color:#1F497D"><o:p> </o:p></span></p> <div style=3D"border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in = 4.0pt"> <div> <div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in = 0in 0in"> <p class=3D"MsoNormal"><b><span style=3D"font-family:"Tahoma",&qu= ot;sans-serif"">From:</span></b><span style=3D"font-family:"Tahom= a","sans-serif""> mext-bounces@ietf.org [mailto:mext-bounces= @ietf.org] <b>On Behalf Of </b>Hampel, K Georg (K Georg)<br> <b>Sent:</b> Thursday, January 20, 2011 12:07 PM<br> <b>To:</b> mext@ietf.org<br> <b>Cc:</b> Hampel, K Georg (K Georg); Klein, Thierry E (Thierry)<br> <b>Subject:</b> [MEXT] Support of route optimization in *absence* of HA<o:p= ></o:p></span></p> </div> </div> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:"Ar= ial","sans-serif"">All,<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:"Ar= ial","sans-serif""><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:"Ar= ial","sans-serif"">We would like to add a proposal to MEXT t= hat permits the mobile to engage into route-optimization in *absence* of a = home agent. <o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:"Ar= ial","sans-serif""><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:"Ar= ial","sans-serif"">Such a feature adds robustness to route o= ptimization in case the HA is temporarily unavailable. Under some circumsta= nces, route optimization *without* HA may be beneficial for performance reasons. Our proposal requires “enhanced route optim= ization for Mobile IPv6” (RFC 4866) as pre-requisite.<o:p></o:p></spa= n></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:"Ar= ial","sans-serif""><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:"Ar= ial","sans-serif"">We would like to obtain some feedback fro= m the MEXT community via this mailing list before we submit the proposal as= a draft to the workgroup. For this purpose, we have enclosed a high-level outline below. Thanks.<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:"Ar= ial","sans-serif""><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:"Ar= ial","sans-serif"">Regards,<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-family:"Arial","s= ans-serif""><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-family:"Arial","s= ans-serif"">Georg Hampel<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-family:"Arial","s= ans-serif"">Networking & Networks Domain<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-family:"Arial","s= ans-serif"">Bell Laboratories<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-family:"Arial","s= ans-serif"">Alcatel-Lucent<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-family:"Arial","s= ans-serif"">=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= <o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-family:"Arial","s= ans-serif""><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:"Ar= ial","sans-serif"">Proposal: Support of Route-Optimization i= n Absence of Home Agent<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:"Ar= ial","sans-serif""><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:"Ar= ial","sans-serif"">ABSTRACT:<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:"Ar= ial","sans-serif"">The proposal allows the mobile to engage = into route optimization (R/O) in *absence* of a HA. This feature increases = robustness when the HA becomes temporarily unavailable. Under some circumstances, R/O *without* HA may be beneficial for performan= ce reasons. This proposal requires “enhanced route optimization for M= obile IPv6” (RFC 4866) as pre-requisite. <o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:"Ar= ial","sans-serif""><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:"Ar= ial","sans-serif"">MOTIVATION:<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:"Ar= ial","sans-serif"">In route optimization (R/O), traffic pack= ets are directly exchanged between hosts without passing the HA. The mobile= , however, still has to interact with the HA. The HA provides (1) location service, (2) a fallback path in case the direct path breaks, = (3) a fallback in case the correspondent does not support the protocol and = (4) security support for R/O-related signaling (i.e. home test). These func= tions come at the following cost:<o:p></o:p></span></p> <p class=3D"MsoNormal" style=3D"margin-left:14.0pt;text-indent:-14.0pt;mso-= list:l3 level1 lfo4"> <![if !supportLists]><span style=3D"font-size:9.0pt;font-family:Symbol"><sp= an style=3D"mso-list:Ignore">·<span style=3D"font:7.0pt "Times = New Roman"">       </span></span></span><![endif]><span style=3D"font-size:10.5pt;font-family:= "Arial","sans-serif"">Handovers may fail when the link = to the HA or the HA itself are down or congested. Mobility is not supported= , when the mobile does not have a HA.<o:p></o:p></span></p> <p class=3D"MsoNormal" style=3D"margin-left:14.0pt;text-indent:-14.0pt;mso-= list:l3 level1 lfo4"> <![if !supportLists]><span style=3D"font-size:9.0pt;font-family:Symbol"><sp= an style=3D"mso-list:Ignore">·<span style=3D"font:7.0pt "Times = New Roman"">       </span></span></span><![endif]><span style=3D"font-size:10.5pt;font-family:= "Arial","sans-serif"">When the mobile starts a session = outside of its home network, it must use a HoA pertaining to its home netwo= rk even if it engages into R/O. This requirement adds air-interface overhead due to mobility headers and processing overhead on = the mobile. This upfront cost incurs even if the mobile does not move durin= g the session.<o:p></o:p></span></p> <p class=3D"MsoNormal" style=3D"margin-left:14.0pt;text-indent:-14.0pt;mso-= list:l3 level1 lfo4"> <![if !supportLists]><span style=3D"font-size:9.0pt;font-family:Symbol"><sp= an style=3D"mso-list:Ignore">·<span style=3D"font:7.0pt "Times = New Roman"">       </span></span></span><![endif]><span style=3D"font-size:10.5pt;font-family:= "Arial","sans-serif"">Signaling handshakes have to be c= onducted between mobile and HA at every mobility event.<o:p></o:p></span></= p> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:"Ar= ial","sans-serif""><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:"Ar= ial","sans-serif"">Currently, the Mobile IPv6 standard famil= y forces the mobile to bear these disadvantages in R/O even if the HA funct= ions are not needed. This specifically applies to scenarios where: <o:p></o:p></span></p> <p class=3D"MsoNormal" style=3D"margin-left:14.0pt;text-indent:-14.0pt;mso-= list:l0 level1 lfo6"> <![if !supportLists]><span style=3D"font-size:9.0pt;font-family:Symbol"><sp= an style=3D"mso-list:Ignore">·<span style=3D"font:7.0pt "Times = New Roman"">       </span></span></span><![endif]><span style=3D"font-size:10.5pt;font-family:= "Arial","sans-serif"">Traffic is based on mobile-initia= ted requests to public servers (majority of present mobile internet traffic= ). The HA’s location service is not needed for such traffic. Location service may also be provided by other means such as Dynamic DNS o= r on application layer (e.g. SIP registrar).<o:p></o:p></span></p> <p class=3D"MsoNormal" style=3D"margin-left:14.0pt;text-indent:-14.0pt;mso-= list:l0 level1 lfo6"> <![if !supportLists]><span style=3D"font-size:9.0pt;font-family:Symbol"><sp= an style=3D"mso-list:Ignore">·<span style=3D"font:7.0pt "Times = New Roman"">       </span></span></span><![endif]><span style=3D"font-size:10.5pt;font-family:= "Arial","sans-serif"">The fallback path through the HA = has little value when it shares the weakest link with the direct path. Sinc= e the weakest link is typically the wireless link, this situation applies to all scenarios where only one air interface is availab= le (this is the typical case rather than the exception).<o:p></o:p></span><= /p> <p class=3D"MsoNormal" style=3D"margin-left:14.0pt;text-indent:-14.0pt;mso-= list:l0 level1 lfo6"> <![if !supportLists]><span style=3D"font-size:9.0pt;font-family:Symbol"><sp= an style=3D"mso-list:Ignore">·<span style=3D"font:7.0pt "Times = New Roman"">       </span></span></span><![endif]><span style=3D"font-size:10.5pt;font-family:= "Arial","sans-serif"">The mobile may know about the cor= respondent’s Mobile-IPv6 support from prior sessions or through means= external to the standard. <o:p></o:p></span></p> <p class=3D"MsoNormal" style=3D"margin-left:14.0pt;text-indent:-14.0pt;mso-= list:l0 level1 lfo6"> <![if !supportLists]><span style=3D"font-size:9.0pt;font-family:Symbol"><sp= an style=3D"mso-list:Ignore">·<span style=3D"font:7.0pt "Times = New Roman"">       </span></span></span><![endif]><span style=3D"font-size:10.5pt;font-family:= "Arial","sans-serif"">The mobile applies the CGA-based = procedure of RFC 4866, which makes the HA’s security support for R/O = unnecessary. This applies to all cases where stateless addressing is permitted. <o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:"Ar= ial","sans-serif""><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:"Ar= ial","sans-serif"">To increase the flexibility and robustnes= s of route-optimized Mobile IPv6, we propose to make the HA an *optional* r= ather than a *mandatory* feature, i.e. to permit operation without HA. This proposal requires some additional extensions to the prese= nt standard.<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:"Ar= ial","sans-serif""><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:"Ar= ial","sans-serif"">HIGH-LEVEL OUTLINE<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:"Ar= ial","sans-serif"">The extensions build on Enhanced Route Op= timization for Mobile IPv6 (RFC 4866) to guarantee sufficient signaling sec= urity. With the absence of a HA, mobility support in R/O can be provided in the following manner:<o:p></o:p></span></p> <p class=3D"MsoNormal" style=3D"margin-left:14.0pt;text-indent:-14.0pt;mso-= list:l1 level1 lfo8"> <![if !supportLists]><span style=3D"font-size:9.0pt;font-family:Symbol"><sp= an style=3D"mso-list:Ignore">·<span style=3D"font:7.0pt "Times = New Roman"">       </span></span></span><![endif]><span style=3D"font-size:10.5pt;font-family:= "Arial","sans-serif"">The mobile starts the traffic ses= sion from any of its currently supported IP addresses. The selected IP addr= ess automatically takes the function of the HoA for this session. This has the advantage that conventional transport is used as lon= g as the mobile does not move, i.e. mobility headers and CoA-vs-HoA mapping= is not needed. The HoA must have been generated via CGA in compliance with= RFC 4866. <o:p></o:p></span></p> <p class=3D"MsoNormal" style=3D"margin-left:14.0pt;text-indent:-14.0pt;mso-= list:l1 level1 lfo8"> <![if !supportLists]><span style=3D"font-size:9.0pt;font-family:Symbol"><sp= an style=3D"mso-list:Ignore">·<span style=3D"font:7.0pt "Times = New Roman"">       </span></span></span><![endif]><span style=3D"font-size:10.5pt;font-family:= "Arial","sans-serif"">The mobile must conduct a “= home-test” from this HoA in compliance with RFC 4866. It may conduct = the home-test prior to session establishment, e.g. to find out if the correspondent supports the standard. <o:p></o:p></span></p> <p class=3D"MsoNormal" style=3D"margin-left:14.0pt;text-indent:-14.0pt;mso-= list:l1 level1 lfo8"> <![if !supportLists]><span style=3D"font-size:9.0pt;font-family:Symbol"><sp= an style=3D"mso-list:Ignore">·<span style=3D"font:7.0pt "Times = New Roman"">       </span></span></span><![endif]><span style=3D"font-size:10.5pt;font-family:= "Arial","sans-serif"">All binding update handshakes are= conducted on the direct path according to RFC 4866.<o:p></o:p></span></p> <p class=3D"MsoNormal" style=3D"margin-left:14.0pt;text-indent:-14.0pt;mso-= list:l1 level1 lfo8"> <![if !supportLists]><span style=3D"font-size:9.0pt;font-family:Symbol"><sp= an style=3D"mso-list:Ignore">·<span style=3D"font:7.0pt "Times = New Roman"">       </span></span></span><![endif]><span style=3D"font-size:10.5pt;font-family:= "Arial","sans-serif"">Since sessions are always started= from a currently supported IP address, temporally overlapping sessions may= use different HoAs. A multi-homed mobile may also decide to start sessions from different simultaneously supported IP addresses. Th= ere is no principle problem here.<o:p></o:p></span></p> <p class=3D"MsoNormal" style=3D"margin-left:14.0pt;text-indent:-14.0pt;mso-= list:l1 level1 lfo8"> <![if !supportLists]><span style=3D"font-size:9.0pt;font-family:Symbol"><sp= an style=3D"mso-list:Ignore">·<span style=3D"font:7.0pt "Times = New Roman"">       </span></span></span><![endif]><span style=3D"font-size:10.5pt;font-family:= "Arial","sans-serif"">Opposed to RFC 4866, the mobile n= eed not perform the CoA registration with the HA.<o:p></o:p></span></p> <p class=3D"MsoNormal" style=3D"margin-left:14.0pt;text-indent:-14.0pt;mso-= list:l1 level1 lfo8"> <![if !supportLists]><span style=3D"font-size:9.0pt;font-family:Symbol"><sp= an style=3D"mso-list:Ignore">·<span style=3D"font:7.0pt "Times = New Roman"">       </span></span></span><![endif]><span style=3D"font-size:10.5pt;font-family:= "Arial","sans-serif"">The mobile must be able to deregi= ster the HoA at the correspondent in case the HoA is not supported anymore.= This ensures that the correspondent does not send packets to the HoA. After deregistration of the HoA, the HoA is still used by high= er protocol layers of ongoing sessions. It must still be included in the mo= bility headers for these sessions.<o:p></o:p></span></p> <p class=3D"MsoNormal" style=3D"margin-left:14.0pt;text-indent:-14.0pt;mso-= list:l1 level1 lfo8"> <![if !supportLists]><span style=3D"font-size:9.0pt;font-family:Symbol"><sp= an style=3D"mso-list:Ignore">·<span style=3D"font:7.0pt "Times = New Roman"">       </span></span></span><![endif]><span style=3D"font-size:10.5pt;font-family:= "Arial","sans-serif"">When the mobile has HA support an= d the HA becomes temporarily unavailable, the mobile simply continues R/O w= ithout HA as outlined in the prior points.<o:p></o:p></span></p> <p class=3D"MsoNormal" style=3D"margin-left:14.0pt;text-indent:-14.0pt;mso-= list:l1 level1 lfo8"> <![if !supportLists]><span style=3D"font-size:9.0pt;font-family:Symbol"><sp= an style=3D"mso-list:Ignore">·<span style=3D"font:7.0pt "Times = New Roman"">       </span></span></span><![endif]><span style=3D"font-size:10.5pt;font-family:= "Arial","sans-serif"">The mobile can publish its IP add= ress in any location service. This allows other hosts to initiate sessions = with the mobile. These sessions enjoy route-optimized mobility support only if the published IP address was generated via CGA in= compliance with RFC 4866.<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:"Ar= ial","sans-serif""><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:"Ar= ial","sans-serif"">OPEN ISSUES<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:"Ar= ial","sans-serif"">These extensions have to be made complian= t with RFC 5648 (multiple CoA registration), RFC 3963 (NEMO) and others. Mo= re discussions are necessary.<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:"Ar= ial","sans-serif""><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:"Ar= ial","sans-serif""><o:p> </o:p></span></p> </div> </div> </div> </body> </html> --_000_98A16B2D00B5724F81E80EF1927A029703A7F6nasanexd01enaqual_-- From georg.hampel@alcatel-lucent.com Fri Jan 21 11:19:50 2011 Return-Path: <georg.hampel@alcatel-lucent.com> X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C8E828C0FA for <mext@core3.amsl.com>; Fri, 21 Jan 2011 11:19:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hXivrQ3uzEhB for <mext@core3.amsl.com>; Fri, 21 Jan 2011 11:19:38 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id 821D53A6A92 for <mext@ietf.org>; Fri, 21 Jan 2011 11:19:37 -0800 (PST) Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id p0LJMNTp019485 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 21 Jan 2011 13:22:23 -0600 (CST) Received: from USNAVSXCHHUB02.ndc.alcatel-lucent.com (usnavsxchhub02.ndc.alcatel-lucent.com [135.3.39.111]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p0LJMMOh028537 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 21 Jan 2011 13:22:23 -0600 Received: from USNAVSXCHMBSA2.ndc.alcatel-lucent.com ([135.3.39.127]) by USNAVSXCHHUB02.ndc.alcatel-lucent.com ([135.3.39.111]) with mapi; Fri, 21 Jan 2011 13:22:22 -0600 From: "Hampel, K Georg (K Georg)" <georg.hampel@alcatel-lucent.com> To: "Laganier, Julien" <julienl@qualcomm.com>, "Hampel, K Georg (K Georg)" <georg.hampel@alcatel-lucent.com>, "mext@ietf.org" <mext@ietf.org> Date: Fri, 21 Jan 2011 13:22:21 -0600 Thread-Topic: Support of route optimization in *absence* of HA Thread-Index: Acu43ZmfXvNW17TRRju54k2cv8RwfQACxVVwAAgzMeAAIwSxMAACJO5g Message-ID: <154773479ED2314980CB638A48FC44348334D271@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> References: <154773479ED2314980CB638A48FC44348334CE4F@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <98A16B2D00B5724F81E80EF1927A0297036BB6@nasanexd01e.na.qualcomm.com> <154773479ED2314980CB638A48FC44348334CFA1@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <98A16B2D00B5724F81E80EF1927A029703A7F6@nasanexd01e.na.qualcomm.com> In-Reply-To: <98A16B2D00B5724F81E80EF1927A029703A7F6@nasanexd01e.na.qualcomm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_154773479ED2314980CB638A48FC44348334D271USNAVSXCHMBSA2n_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10 Cc: "Klein, Thierry E \(Thierry\)" <thierry.klein@alcatel-lucent.com> Subject: Re: [MEXT] Support of route optimization in *absence* of HA X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG <mext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/mext> List-Post: <mailto:mext@ietf.org> List-Help: <mailto:mext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 21 Jan 2011 19:19:50 -0000 --_000_154773479ED2314980CB638A48FC44348334D271USNAVSXCHMBSA2n_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Julien, Thanks for the info. I like your proposal. CGA provides cryptographic secur= ity without need for trust-relationships, PKI, pre-shared keys, etc. 1) When IPsec is replaced by CGA, MN only proves the authenticity of its Ho= A to the HA. It does not authenticate itself in absolute terms, i.e. via me= ans of strong authentication as required by IPsec or TLS. How would the HA = know that this MN is authorized to use the HA's services? 2) Do we have any idea to what extend stateless addressing is "supported"? = Does (or will) 3GPP allow stateless addressing? -Georg ________________________________ From: Laganier, Julien [mailto:julienl@qualcomm.com] Sent: Friday, January 21, 2011 1:06 PM To: Hampel, K Georg (K Georg); mext@ietf.org Cc: Klein, Thierry E (Thierry) Subject: RE: Support of route optimization in *absence* of HA Georg, Thanks for clarifying, this is what I thought. FWIW, I've tried to extend t= he RFC 4866 to secure bindings between the MN and the HA in http://tools.ie= tf.org/html/draft-laganier-mext-cga-01 --julien From: Hampel, K Georg (K Georg) [mailto:georg.hampel@alcatel-lucent.com] Sent: Thursday, January 20, 2011 5:25 PM To: Laganier, Julien; mext@ietf.org Cc: Klein, Thierry E (Thierry) Subject: RE: Support of route optimization in *absence* of HA Julien, The intentions of Homeless MIPv6 are similar to those of our proposal. In contrast to Homeless MIPv6, our proposal requires only minimal upgrades = to the present standard and implementation. (Homeless MIPv6 requires change= s to the TCP/UDP and requires AH, for instance). Here's the core idea of HA-free R/O: 1) When starting a session, the MN self-declares its current IP address a= s the "HoA" for this session. This automatically means that it resides in i= ts "home network" and can conduct the home test directly with CN, i.e. no h= ome registration required. 2) All further BU/BA signaling is done directly with CN according to RFC = 4866. 3) All further signaling with HA is simply omitted. Our proposal builds on "enhanced route optimization" (RFC 4866), which prov= ides a nice security solution for R/O and creates the ground for HA-free op= eration. Little changes are required: e.g. MN must be able to deregister its HoA at = CN, etc. Regards, Georg ________________________________ From: Laganier, Julien [mailto:julienl@qualcomm.com] Sent: Thursday, January 20, 2011 4:27 PM To: Hampel, K Georg (K Georg); mext@ietf.org Cc: Klein, Thierry E (Thierry) Subject: RE: Support of route optimization in *absence* of HA Georg, Is it correct that functionally your proposal is similar to Homeless Mobile= IPv6: http://tools.ietf.org/html/draft-nikander-mobileip-homelessv6-01 Best, --julien From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of Ham= pel, K Georg (K Georg) Sent: Thursday, January 20, 2011 12:07 PM To: mext@ietf.org Cc: Hampel, K Georg (K Georg); Klein, Thierry E (Thierry) Subject: [MEXT] Support of route optimization in *absence* of HA All, We would like to add a proposal to MEXT that permits the mobile to engage i= nto route-optimization in *absence* of a home agent. Such a feature adds robustness to route optimization in case the HA is temp= orarily unavailable. Under some circumstances, route optimization *without*= HA may be beneficial for performance reasons. Our proposal requires "enhan= ced route optimization for Mobile IPv6" (RFC 4866) as pre-requisite. We would like to obtain some feedback from the MEXT community via this mail= ing list before we submit the proposal as a draft to the workgroup. For thi= s purpose, we have enclosed a high-level outline below. Thanks. Regards, Georg Hampel Networking & Networks Domain Bell Laboratories Alcatel-Lucent =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Proposal: Support of Route-Optimization in Absence of Home Agent ABSTRACT: The proposal allows the mobile to engage into route optimization (R/O) in *= absence* of a HA. This feature increases robustness when the HA becomes tem= porarily unavailable. Under some circumstances, R/O *without* HA may be ben= eficial for performance reasons. This proposal requires "enhanced route opt= imization for Mobile IPv6" (RFC 4866) as pre-requisite. MOTIVATION: In route optimization (R/O), traffic packets are directly exchanged between= hosts without passing the HA. The mobile, however, still has to interact w= ith the HA. The HA provides (1) location service, (2) a fallback path in ca= se the direct path breaks, (3) a fallback in case the correspondent does no= t support the protocol and (4) security support for R/O-related signaling (= i.e. home test). These functions come at the following cost: * Handovers may fail when the link to the HA or the HA itself are dow= n or congested. Mobility is not supported, when the mobile does not have a = HA. * When the mobile starts a session outside of its home network, it mu= st use a HoA pertaining to its home network even if it engages into R/O. Th= is requirement adds air-interface overhead due to mobility headers and proc= essing overhead on the mobile. This upfront cost incurs even if the mobile = does not move during the session. * Signaling handshakes have to be conducted between mobile and HA at = every mobility event. Currently, the Mobile IPv6 standard family forces the mobile to bear these = disadvantages in R/O even if the HA functions are not needed. This specific= ally applies to scenarios where: * Traffic is based on mobile-initiated requests to public servers (ma= jority of present mobile internet traffic). The HA's location service is no= t needed for such traffic. Location service may also be provided by other m= eans such as Dynamic DNS or on application layer (e.g. SIP registrar). * The fallback path through the HA has little value when it shares th= e weakest link with the direct path. Since the weakest link is typically th= e wireless link, this situation applies to all scenarios where only one air= interface is available (this is the typical case rather than the exception= ). * The mobile may know about the correspondent's Mobile-IPv6 support f= rom prior sessions or through means external to the standard. * The mobile applies the CGA-based procedure of RFC 4866, which makes= the HA's security support for R/O unnecessary. This applies to all cases w= here stateless addressing is permitted. To increase the flexibility and robustness of route-optimized Mobile IPv6, = we propose to make the HA an *optional* rather than a *mandatory* feature, = i.e. to permit operation without HA. This proposal requires some additional= extensions to the present standard. HIGH-LEVEL OUTLINE The extensions build on Enhanced Route Optimization for Mobile IPv6 (RFC 48= 66) to guarantee sufficient signaling security. With the absence of a HA, m= obility support in R/O can be provided in the following manner: * The mobile starts the traffic session from any of its currently sup= ported IP addresses. The selected IP address automatically takes the functi= on of the HoA for this session. This has the advantage that conventional tr= ansport is used as long as the mobile does not move, i.e. mobility headers = and CoA-vs-HoA mapping is not needed. The HoA must have been generated via = CGA in compliance with RFC 4866. * The mobile must conduct a "home-test" from this HoA in compliance w= ith RFC 4866. It may conduct the home-test prior to session establishment, = e.g. to find out if the correspondent supports the standard. * All binding update handshakes are conducted on the direct path acco= rding to RFC 4866. * Since sessions are always started from a currently supported IP add= ress, temporally overlapping sessions may use different HoAs. A multi-homed= mobile may also decide to start sessions from different simultaneously sup= ported IP addresses. There is no principle problem here. * Opposed to RFC 4866, the mobile need not perform the CoA registrati= on with the HA. * The mobile must be able to deregister the HoA at the correspondent = in case the HoA is not supported anymore. This ensures that the corresponde= nt does not send packets to the HoA. After deregistration of the HoA, the H= oA is still used by higher protocol layers of ongoing sessions. It must sti= ll be included in the mobility headers for these sessions. * When the mobile has HA support and the HA becomes temporarily unava= ilable, the mobile simply continues R/O without HA as outlined in the prior= points. * The mobile can publish its IP address in any location service. This= allows other hosts to initiate sessions with the mobile. These sessions en= joy route-optimized mobility support only if the published IP address was g= enerated via CGA in compliance with RFC 4866. OPEN ISSUES These extensions have to be made compliant with RFC 5648 (multiple CoA regi= stration), RFC 3963 (NEMO) and others. More discussions are necessary. --_000_154773479ED2314980CB638A48FC44348334D271USNAVSXCHMBSA2n_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:x=3D"urn:schemas-microsoft-com:office:excel" xmlns:p=3D"urn:schemas-m= icrosoft-com:office:powerpoint" xmlns:a=3D"urn:schemas-microsoft-com:office= :access" xmlns:dt=3D"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s=3D"= uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs=3D"urn:schemas-microsof= t-com:rowset" xmlns:z=3D"#RowsetSchema" xmlns:b=3D"urn:schemas-microsoft-co= m:office:publisher" xmlns:ss=3D"urn:schemas-microsoft-com:office:spreadshee= t" xmlns:c=3D"urn:schemas-microsoft-com:office:component:spreadsheet" xmlns= :odc=3D"urn:schemas-microsoft-com:office:odc" xmlns:oa=3D"urn:schemas-micro= soft-com:office:activation" xmlns:html=3D"http://www.w3.org/TR/REC-html40" = xmlns:q=3D"http://schemas.xmlsoap.org/soap/envelope/" xmlns:rtc=3D"http://m= icrosoft.com/officenet/conferencing" xmlns:D=3D"DAV:" xmlns:Repl=3D"http://= schemas.microsoft.com/repl/" xmlns:mt=3D"http://schemas.microsoft.com/share= point/soap/meetings/" xmlns:x2=3D"http://schemas.microsoft.com/office/excel= /2003/xml" xmlns:ppda=3D"http://www.passport.com/NameSpace.xsd" xmlns:ois= =3D"http://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir=3D"http://= schemas.microsoft.com/sharepoint/soap/directory/" xmlns:ds=3D"http://www.w3= .org/2000/09/xmldsig#" xmlns:dsp=3D"http://schemas.microsoft.com/sharepoint= /dsp" xmlns:udc=3D"http://schemas.microsoft.com/data/udc" xmlns:xsd=3D"http= ://www.w3.org/2001/XMLSchema" xmlns:sub=3D"http://schemas.microsoft.com/sha= repoint/soap/2002/1/alerts/" xmlns:ec=3D"http://www.w3.org/2001/04/xmlenc#"= xmlns:sp=3D"http://schemas.microsoft.com/sharepoint/" xmlns:sps=3D"http://= schemas.microsoft.com/sharepoint/soap/" xmlns:xsi=3D"http://www.w3.org/2001= /XMLSchema-instance" xmlns:udcs=3D"http://schemas.microsoft.com/data/udc/so= ap" xmlns:udcxf=3D"http://schemas.microsoft.com/data/udc/xmlfile" xmlns:udc= p2p=3D"http://schemas.microsoft.com/data/udc/parttopart" xmlns:st=3D"" = xmlns:st1=3D"urn:schemas-microsoft-com:office:smarttags" xmlns=3D"http://ww= w.w3.org/TR/REC-html40" xmlns:ns0=3D"http://schemas.microsoft.com/sharepoint/soap/workflow/" xmlns:ns1=3D"http://schemas.microsoft.com/office/2006/digsig-setup" xmlns:ns2=3D"http://schemas.microsoft.com/office/2006/digsig" xmlns:ns3=3D"http://schemas.openxmlformats.org/package/2006/digital-signatu= re" xmlns:ns4=3D"http://schemas.openxmlformats.org/markup-compatibility/2006" xmlns:ns5=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns:ns6=3D"http://schemas.openxmlformats.org/package/2006/relationships" xmlns:ns7=3D"http://microsoft.com/sharepoint/webpartpages" xmlns:ns8=3D"http://schemas.microsoft.com/exchange/services/2006/types" xmlns:ns9=3D"http://schemas.microsoft.com/exchange/services/2006/messages" xmlns:ns10=3D"http://schemas.microsoft.com/sharepoint/soap/SlideLibrary/" xmlns:ns11=3D"http://microsoft.com/webservices/SharePointPortalServer/Publi= shedLinksService" xmlns:ns12=3D"urn:schemas-microsoft-com:"> <head> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; charset=3Dus-ascii"= > <meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)"> <!--[if !mso]> <style> v\:* {behavior:url(#default#VML);} o\:* {behavior:url(#default#VML);} w\:* {behavior:url(#default#VML);} .shape {behavior:url(#default#VML);} </style> <![endif]--><o:SmartTagType namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags" name=3D"State"= /> <o:SmartTagType namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags" name=3D"City"/> <o:SmartTagType namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags" name=3D"place"/> <o:SmartTagType namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags" name=3D"PersonName"/> <!--[if !mso]> <style> st1\:*{behavior:url(#default#ieooui) } </style> <![endif]--> <style> <!--a:link {mso-style-priority:99;} span.MSOHYPERLINK {mso-style-priority:99;} a:visited {mso-style-priority:99;} span.MSOHYPERLINKFOLLOWED {mso-style-priority:99;} /* Font Definitions */ @font-face {font-family:SimSun; panose-1:2 1 6 0 3 1 1 1 1 1;} @font-face {font-family:Tahoma; panose-1:2 11 6 4 3 5 4 4 2 4;} @font-face {font-family:"\@SimSun"; panose-1:2 1 6 0 3 1 1 1 1 1;} @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0pt; margin-bottom:.0001pt; font-size:10.0pt; font-family:"Times New Roman";} a:link, span.MsoHyperlink {color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {color:purple; text-decoration:underline;} span.EmailStyle17 {mso-style-type:personal; font-family:Arial; color:windowtext;} span.EmailStyle18 {mso-style-type:personal; font-family:Calibri; color:#1F497D;} span.EmailStyle19 {mso-style-type:personal; font-family:Arial; color:navy;} span.EmailStyle20 {mso-style-type:personal; font-family:Calibri; color:#1F497D;} span.EmailStyle21 {mso-style-type:personal-reply; font-family:Arial; color:navy;} @page Section1 {size:612.0pt 792.0pt; margin:72.0pt 90.0pt 72.0pt 90.0pt;} div.Section1 {page:Section1;} /* List Definitions */ @list l0 {mso-list-id:462961695; mso-list-type:hybrid; mso-list-template-ids:-2116359956 -727278766 67698691 67698693 67698689 67= 698691 67698693 67698689 67698691 67698693;} @list l0:level1 {mso-level-number-format:bullet; mso-level-text:\F0B7; mso-level-tab-stop:-5.0pt; mso-level-number-position:left; margin-left:14.0pt; text-indent:-14.0pt; mso-ansi-font-size:9.0pt; font-family:Symbol;} @list l0:level2 {mso-level-tab-stop:72.0pt; mso-level-number-position:left; text-indent:-18.0pt;} @list l0:level3 {mso-level-tab-stop:108.0pt; mso-level-number-position:left; text-indent:-18.0pt;} @list l0:level4 {mso-level-tab-stop:144.0pt; mso-level-number-position:left; text-indent:-18.0pt;} @list l0:level5 {mso-level-tab-stop:180.0pt; mso-level-number-position:left; text-indent:-18.0pt;} @list l0:level6 {mso-level-tab-stop:216.0pt; mso-level-number-position:left; text-indent:-18.0pt;} @list l0:level7 {mso-level-tab-stop:252.0pt; mso-level-number-position:left; text-indent:-18.0pt;} @list l0:level8 {mso-level-tab-stop:288.0pt; mso-level-number-position:left; text-indent:-18.0pt;} @list l0:level9 {mso-level-tab-stop:324.0pt; mso-level-number-position:left; text-indent:-18.0pt;} @list l1 {mso-list-id:823199790; mso-list-type:hybrid; mso-list-template-ids:-198536934 -727278766 67698691 67698693 67698689 676= 98691 67698693 67698689 67698691 67698693;} @list l1:level1 {mso-level-number-format:bullet; mso-level-text:\F0B7; mso-level-tab-stop:-5.0pt; mso-level-number-position:left; margin-left:14.0pt; text-indent:-14.0pt; mso-ansi-font-size:9.0pt; font-family:Symbol;} @list l1:level2 {mso-level-tab-stop:72.0pt; mso-level-number-position:left; text-indent:-18.0pt;} @list l1:level3 {mso-level-tab-stop:108.0pt; mso-level-number-position:left; text-indent:-18.0pt;} @list l1:level4 {mso-level-tab-stop:144.0pt; mso-level-number-position:left; text-indent:-18.0pt;} @list l1:level5 {mso-level-tab-stop:180.0pt; mso-level-number-position:left; text-indent:-18.0pt;} @list l1:level6 {mso-level-tab-stop:216.0pt; mso-level-number-position:left; text-indent:-18.0pt;} @list l1:level7 {mso-level-tab-stop:252.0pt; mso-level-number-position:left; text-indent:-18.0pt;} @list l1:level8 {mso-level-tab-stop:288.0pt; mso-level-number-position:left; text-indent:-18.0pt;} @list l1:level9 {mso-level-tab-stop:324.0pt; mso-level-number-position:left; text-indent:-18.0pt;} @list l2 {mso-list-id:1836452376; mso-list-type:hybrid; mso-list-template-ids:-1378300656 -1558151418 67698713 67698715 67698703 6= 7698713 67698715 67698703 67698713 67698715;} @list l2:level1 {mso-level-text:"%1\)"; mso-level-tab-stop:36.0pt; mso-level-number-position:left; text-indent:-18.0pt;} @list l2:level2 {mso-level-tab-stop:72.0pt; mso-level-number-position:left; text-indent:-18.0pt;} @list l2:level3 {mso-level-tab-stop:108.0pt; mso-level-number-position:left; text-indent:-18.0pt;} @list l2:level4 {mso-level-tab-stop:144.0pt; mso-level-number-position:left; text-indent:-18.0pt;} @list l2:level5 {mso-level-tab-stop:180.0pt; mso-level-number-position:left; text-indent:-18.0pt;} @list l2:level6 {mso-level-tab-stop:216.0pt; mso-level-number-position:left; text-indent:-18.0pt;} @list l2:level7 {mso-level-tab-stop:252.0pt; mso-level-number-position:left; text-indent:-18.0pt;} @list l2:level8 {mso-level-tab-stop:288.0pt; mso-level-number-position:left; text-indent:-18.0pt;} @list l2:level9 {mso-level-tab-stop:324.0pt; mso-level-number-position:left; text-indent:-18.0pt;} @list l3 {mso-list-id:2000302011; mso-list-type:hybrid; mso-list-template-ids:-1553676858 -727278766 67698691 67698693 67698689 67= 698691 67698693 67698689 67698691 67698693;} @list l3:level1 {mso-level-number-format:bullet; mso-level-text:\F0B7; mso-level-tab-stop:-5.0pt; mso-level-number-position:left; margin-left:14.0pt; text-indent:-14.0pt; mso-ansi-font-size:9.0pt; font-family:Symbol;} @list l3:level2 {mso-level-tab-stop:72.0pt; mso-level-number-position:left; text-indent:-18.0pt;} @list l3:level3 {mso-level-tab-stop:108.0pt; mso-level-number-position:left; text-indent:-18.0pt;} @list l3:level4 {mso-level-tab-stop:144.0pt; mso-level-number-position:left; text-indent:-18.0pt;} @list l3:level5 {mso-level-tab-stop:180.0pt; mso-level-number-position:left; text-indent:-18.0pt;} @list l3:level6 {mso-level-tab-stop:216.0pt; mso-level-number-position:left; text-indent:-18.0pt;} @list l3:level7 {mso-level-tab-stop:252.0pt; mso-level-number-position:left; text-indent:-18.0pt;} @list l3:level8 {mso-level-tab-stop:288.0pt; mso-level-number-position:left; text-indent:-18.0pt;} @list l3:level9 {mso-level-tab-stop:324.0pt; mso-level-number-position:left; text-indent:-18.0pt;} ol {margin-bottom:0pt;} ul {margin-bottom:0pt;} --> </style> <!--[if gte mso 9]><xml> <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext=3D"edit"> <o:idmap v:ext=3D"edit" data=3D"1" /> </o:shapelayout></xml><![endif]--> </head> <body lang=3DEN-US link=3Dblue vlink=3Dpurple> <div class=3DSection1> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style= =3D'font-size: 10.0pt;font-family:Arial;color:navy'>Julien,<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style= =3D'font-size: 10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style= =3D'font-size: 10.0pt;font-family:Arial;color:navy'>Thanks for the info. I like your propo= sal. CGA provides cryptographic security without need for trust-relationships, P= KI, pre-shared keys, etc.<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style= =3D'font-size: 10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style= =3D'font-size: 10.0pt;font-family:Arial;color:navy'>1) When IPsec is replaced by <st1:plac= e w:st=3D"on"><st1:City w:st=3D"on">CGA</st1:City>, <st1:State w:st=3D"on">MN= </st1:State></st1:place> only proves the authenticity of its HoA to the HA. It does not authenticate itself in absolute terms, i.e. via means of strong authentication as requir= ed by IPsec or TLS. How would the HA know that this MN is authorized to use th= e HA’s services?  <o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style= =3D'font-size: 10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style= =3D'font-size: 10.0pt;font-family:Arial;color:navy'>2) Do we have any idea to what extend stateless addressing is “supported”? Does (or will) 3GPP allow = stateless addressing?<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style= =3D'font-size: 10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style= =3D'font-size: 10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style= =3D'font-size: 10.0pt;font-family:Arial;color:navy'>-Georg<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style= =3D'font-size: 10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style= =3D'font-size: 10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p> <div> <div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font siz= e=3D3 face=3D"Times New Roman"><span style=3D'font-size:12.0pt'> <hr size=3D2 width=3D"100%" align=3Dcenter tabindex=3D-1> </span></font></div> <p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span style=3D'font-si= ze:10.0pt; font-family:Tahoma;font-weight:bold'>From:</span></font></b><font face=3DTa= homa><span style=3D'font-family:Tahoma'> Laganier, Julien [mailto:julienl@qualcomm.com= ] <br> <b><span style=3D'font-weight:bold'>Sent:</span></b> Friday, January 21, 20= 11 1:06 PM<br> <b><span style=3D'font-weight:bold'>To:</span></b> <st1:PersonName w:st=3D"= on">Hampel, K Georg</st1:PersonName> (K Georg); <st1:PersonName w:st=3D"on">mext@ietf.= org</st1:PersonName><br> <b><span style=3D'font-weight:bold'>Cc:</span></b> <st1:PersonName w:st=3D"= on">Klein, Thierry E</st1:PersonName> (Thierry)<br> <b><span style=3D'font-weight:bold'>Subject:</span></b> RE: Support of rout= e optimization in *absence* of HA</span></font><font size=3D3><span style=3D'font-size:12.0pt'><o:p></o:p></span></font></p> </div> <p class=3DMsoNormal><font size=3D2 face=3D"Times New Roman"><span style=3D= 'font-size: 10.0pt'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" face=3DCalibri><span style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'>Georg,<o:p></o= :p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" face=3DCalibri><span style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'><o:p> </o= :p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" face=3DCalibri><span style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'>Thanks for clarifying, this is what I thought. FWIW, I’ve tried to extend the RF= C 4866 to secure bindings between the MN and the HA in </span></font><a href=3D"http://tools.ietf.org/html/draft-laganier-mext-cga-01">http://tools= .ietf.org/html/draft-laganier-mext-cga-01</a><o:p></o:p></p> <p class=3DMsoNormal><font size=3D2 face=3D"Times New Roman"><span style=3D= 'font-size: 10.0pt'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" face=3DCalibri><span style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'>--julien<o:p><= /o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" face=3DCalibri><span style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'><o:p> </o= :p></span></font></p> <div style=3D'border:none;border-left:solid blue 1.5pt;padding:0pt 0pt 0pt = 4.0pt'> <div> <div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0pt = 0pt 0pt'> <p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span style=3D'font-si= ze:10.0pt; font-family:Tahoma;font-weight:bold'>From:</span></font></b><font face=3DTa= homa><span style=3D'font-family:Tahoma'> <st1:PersonName w:st=3D"on">Hampel, K Georg</= st1:PersonName> (K Georg) [mailto:georg.hampel@alcatel-lucent.com] <br> <b><span style=3D'font-weight:bold'>Sent:</span></b> Thursday, January 20, = 2011 5:25 PM<br> <b><span style=3D'font-weight:bold'>To:</span></b> Laganier, Julien; <st1:P= ersonName w:st=3D"on">mext@ietf.org</st1:PersonName><br> <b><span style=3D'font-weight:bold'>Cc:</span></b> <st1:PersonName w:st=3D"= on">Klein, Thierry E</st1:PersonName> (Thierry)<br> <b><span style=3D'font-weight:bold'>Subject:</span></b> RE: Support of rout= e optimization in *absence* of HA<o:p></o:p></span></font></p> </div> </div> <p class=3DMsoNormal><font size=3D2 face=3D"Times New Roman"><span style=3D= 'font-size: 10.0pt'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span lang=3D= EN style=3D'font-size:10.0pt;font-family:Arial;color:navy'>Julien,<o:p></o:p><= /span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span lang=3D= EN style=3D'font-size:10.0pt;font-family:Arial;color:navy'><o:p> </o:p></= span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span lang=3D= EN style=3D'font-size:10.0pt;font-family:Arial;color:navy'>The intentions of Homeless MIPv6 are similar to those of our proposal. <o:p></o:p></span></fo= nt></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span lang=3D= EN style=3D'font-size:10.0pt;font-family:Arial;color:navy'><o:p> </o:p></= span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span lang=3D= EN style=3D'font-size:10.0pt;font-family:Arial;color:navy'>In contrast to Home= less MIPv6, our proposal requires only minimal upgrades to the present standard = and implementation. (Homeless MIPv6 requires changes to the TCP/UDP and require= s AH, for instance).<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span lang=3D= EN style=3D'font-size:10.0pt;font-family:Arial;color:navy'><o:p> </o:p></= span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span lang=3D= EN style=3D'font-size:10.0pt;font-family:Arial;color:navy'>Here’s the co= re idea of HA-free R/O: <o:p></o:p></span></font></p> <p class=3DMsoNormal style=3D'margin-left:36.0pt;text-indent:-18.0pt;mso-li= st:l2 level1 lfo2'><![if !supportLists]><font size=3D2 color=3Dnavy face=3DArial><span lang=3DEN style=3D'font-size:10.0p= t;font-family: Arial;color:navy'><span style=3D'mso-list:Ignore'>1)<font size=3D1 face=3D"Times New Roman"><span style=3D'font:7.0pt "Times New Roman"'> = ;  </span></font></span></span></font><![endif]><font color=3Dnavy face=3DArial><span lang=3DEN style=3D'font-family:Arial;color:= navy'>When starting a session, the MN self-declares its current IP address as the R= 20;HoA” for this session. This automatically means that it resides in its “ho= me network” and can conduct the home test directly with CN, i.e. no home registration required.<o:p></o:p></span></font></p> <p class=3DMsoNormal style=3D'margin-left:36.0pt;text-indent:-18.0pt;mso-li= st:l2 level1 lfo2'><![if !supportLists]><font size=3D2 color=3Dnavy face=3DArial><span lang=3DEN style=3D'font-size:10.0p= t;font-family: Arial;color:navy'><span style=3D'mso-list:Ignore'>2)<font size=3D1 face=3D"Times New Roman"><span style=3D'font:7.0pt "Times New Roman"'> = ;  </span></font></span></span></font><![endif]><font color=3Dnavy face=3DArial><span lang=3DEN style=3D'font-family:Arial;color:= navy'>All further BU/BA signaling is done directly with CN according to RFC 4866.<o:p= ></o:p></span></font></p> <p class=3DMsoNormal style=3D'margin-left:36.0pt;text-indent:-18.0pt;mso-li= st:l2 level1 lfo2'><![if !supportLists]><font size=3D2 color=3Dnavy face=3DArial><span lang=3DEN style=3D'font-size:10.0p= t;font-family: Arial;color:navy'><span style=3D'mso-list:Ignore'>3)<font size=3D1 face=3D"Times New Roman"><span style=3D'font:7.0pt "Times New Roman"'> = ;  </span></font></span></span></font><![endif]><font color=3Dnavy face=3DArial><span lang=3DEN style=3D'font-family:Arial;color:= navy'>All further signaling with HA is simply omitted.<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span lang=3D= EN style=3D'font-size:10.0pt;font-family:Arial;color:navy'><o:p> </o:p></= span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span lang=3D= EN style=3D'font-size:10.0pt;font-family:Arial;color:navy'>Our proposal builds= on “enhanced route optimization” (RFC 4866), which provides a nice= security solution for R/O and creates the ground for HA-free operation.<o:p></o:p></= span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span lang=3D= EN style=3D'font-size:10.0pt;font-family:Arial;color:navy'>Little changes are required: e.g. MN must be able to deregister its HoA at CN, etc.<o:p></o:p>= </span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span lang=3D= EN style=3D'font-size:10.0pt;font-family:Arial;color:navy'><o:p> </o:p></= span></font></p> <div> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span lang=3D= EN style=3D'font-size:10.0pt;font-family:Arial;color:navy'>Regards,<o:p></o:p>= </span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span lang=3D= EN style=3D'font-size:10.0pt;font-family:Arial;color:navy'><o:p> </o:p></= span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span lang=3D= EN style=3D'font-size:10.0pt;font-family:Arial;color:navy'>Georg<o:p></o:p></s= pan></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3D"Times New Roman"><= span style=3D'font-size:10.0pt;color:navy'><o:p> </o:p></span></font></p> </div> <div> <div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font siz= e=3D3 face=3D"Times New Roman"><span style=3D'font-size:12.0pt'> <hr size=3D2 width=3D"100%" align=3Dcenter> </span></font></div> <p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span style=3D'font-si= ze:10.0pt; font-family:Tahoma;font-weight:bold'>From:</span></font></b><font face=3DTa= homa><span style=3D'font-family:Tahoma'> Laganier, Julien [mailto:julienl@qualcomm.com= ] <br> <b><span style=3D'font-weight:bold'>Sent:</span></b> Thursday, January 20, = 2011 4:27 PM<br> <b><span style=3D'font-weight:bold'>To:</span></b> <st1:PersonName w:st=3D"= on">Hampel, K Georg</st1:PersonName> (K Georg); <st1:PersonName w:st=3D"on">mext@ietf.= org</st1:PersonName><br> <b><span style=3D'font-weight:bold'>Cc:</span></b> <st1:PersonName w:st=3D"= on">Klein, Thierry E</st1:PersonName> (Thierry)<br> <b><span style=3D'font-weight:bold'>Subject:</span></b> RE: Support of rout= e optimization in *absence* of HA</span></font><font size=3D3><span style=3D'font-size:12.0pt'><o:p></o:p></span></font></p> </div> <p class=3DMsoNormal><font size=3D2 face=3D"Times New Roman"><span style=3D= 'font-size: 10.0pt'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" face=3DCalibri><span style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'>Georg,<o:p></o= :p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" face=3DCalibri><span style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'><o:p> </o= :p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" face=3DCalibri><span style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'>Is it correct = that functionally your proposal is similar to Homeless Mobile IPv6:<o:p></o:p></span></font><= /p> <p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" face=3DCalibri><span style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'><o:p> </o= :p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3D"Times New Roman"><span style=3D= 'font-size: 10.0pt'><a href=3D"http://tools.ietf.org/html/draft-nikander-mobileip-homelessv6-01">h= ttp://tools.ietf.org/html/draft-nikander-mobileip-homelessv6-01</a><o:p></o= :p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3D"Times New Roman"><span style=3D= 'font-size: 10.0pt'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" face=3DCalibri><span style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'>Best,<o:p></o:= p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" face=3DCalibri><span style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'><o:p> </o= :p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" face=3DCalibri><span style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'>--julien<o:p><= /o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" face=3DCalibri><span style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'><o:p> </o= :p></span></font></p> <div style=3D'border:none;border-left:solid blue 1.5pt;padding:0pt 0pt 0pt = 4.0pt'> <div> <div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0pt = 0pt 0pt'> <p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span style=3D'font-si= ze:10.0pt; font-family:Tahoma;font-weight:bold'>From:</span></font></b><font face=3DTa= homa><span style=3D'font-family:Tahoma'> mext-bounces@ietf.org [mailto:mext-bounces@ie= tf.org] <b><span style=3D'font-weight:bold'>On Behalf Of </span></b><st1:PersonName w:st=3D"on">Hampel, K Georg</st1:PersonName> (K Georg)<br> <b><span style=3D'font-weight:bold'>Sent:</span></b> Thursday, January 20, = 2011 12:07 PM<br> <b><span style=3D'font-weight:bold'>To:</span></b> <st1:PersonName w:st=3D"= on">mext@ietf.org</st1:PersonName><br> <b><span style=3D'font-weight:bold'>Cc:</span></b> <st1:PersonName w:st=3D"= on">Hampel, K Georg</st1:PersonName> (K Georg); <st1:PersonName w:st=3D"on">Klein, Thi= erry E</st1:PersonName> (Thierry)<br> <b><span style=3D'font-weight:bold'>Subject:</span></b> [MEXT] Support of r= oute optimization in *absence* of HA<o:p></o:p></span></font></p> </div> </div> <p class=3DMsoNormal><font size=3D2 face=3D"Times New Roman"><span style=3D= 'font-size: 10.0pt'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1= 0.5pt; font-family:Arial'>All,<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1= 0.5pt; font-family:Arial'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1= 0.5pt; font-family:Arial'>We would like to add a proposal to MEXT that permits the mobile to engage into route-optimization in *absence* of a home agent. <o:p= ></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1= 0.5pt; font-family:Arial'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1= 0.5pt; font-family:Arial'>Such a feature adds robustness to route optimization in = case the HA is temporarily unavailable. Under some circumstances, route optimiza= tion *without* HA may be beneficial for performance reasons. Our proposal requir= es “enhanced route optimization for Mobile IPv6” (RFC 4866) as pre= -requisite.<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1= 0.5pt; font-family:Arial'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1= 0.5pt; font-family:Arial'>We would like to obtain some feedback from the MEXT community via this mailing list before we submit the proposal as a draft to= the workgroup. For this purpose, we have enclosed a high-level outline below. Thanks.<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1= 0.5pt; font-family:Arial'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1= 0.5pt; font-family:Arial'>Regards,<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1= 0.0pt; font-family:Arial'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><st1:PersonName w:st=3D"on"><font size=3D2 face=3DAria= l><span style=3D'font-size:10.0pt;font-family:Arial'>Georg Hampel</span></font></s= t1:PersonName><font face=3DArial><span style=3D'font-family:Arial'><o:p></o:p></span></font></p= > <p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1= 0.0pt; font-family:Arial'>Networking & Networks Domain<o:p></o:p></span></font= ></p> <p class=3DMsoNormal><st1:City w:st=3D"on"><st1:place w:st=3D"on"><font siz= e=3D2 face=3DArial><span style=3D'font-size:10.0pt;font-family:Arial'>Bell</spa= n></font></st1:place></st1:City><font face=3DArial><span style=3D'font-family:Arial'> Laboratories<o:p></o:p></sp= an></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1= 0.0pt; font-family:Arial'>Alcatel-Lucent<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1= 0.0pt; font-family:Arial'>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1= 0.0pt; font-family:Arial'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1= 0.5pt; font-family:Arial'>Proposal: Support of Route-Optimization in Absence of Ho= me Agent<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1= 0.5pt; font-family:Arial'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1= 0.5pt; font-family:Arial'>ABSTRACT:<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1= 0.5pt; font-family:Arial'>The proposal allows the mobile to engage into route optimization (R/O) in *absence* of a HA. This feature increases robustness = when the HA becomes temporarily unavailable. Under some circumstances, R/O *with= out* HA may be beneficial for performance reasons. This proposal requires “= ;enhanced route optimization for Mobile IPv6” (RFC 4866) as pre-requisite. <o:p= ></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1= 0.5pt; font-family:Arial'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1= 0.5pt; font-family:Arial'>MOTIVATION:<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1= 0.5pt; font-family:Arial'>In route optimization (R/O), traffic packets are directl= y exchanged between hosts without passing the HA. The mobile, however, still = has to interact with the HA. The HA provides (1) location service, (2) a fallba= ck path in case the direct path breaks, (3) a fallback in case the corresponde= nt does not support the protocol and (4) security support for R/O-related signaling (i.e. home test). These functions come at the following cost:<o:p= ></o:p></span></font></p> <p class=3DMsoNormal style=3D'margin-left:14.0pt;text-indent:-14.0pt;mso-li= st:l3 level1 lfo4'><![if !supportLists]><font size=3D1 face=3DSymbol><span style=3D'font-size:9.0pt;font-family:Symbol'><= span style=3D'mso-list:Ignore'>·<font size=3D1 face=3D"Times New Roman"><= span style=3D'font:7.0pt "Times New Roman"'>      = </span></font></span></span></font><![endif]><font size=3D2 face=3DArial><span style=3D'font-size:10.5pt;font-family:Arial'>Ha= ndovers may fail when the link to the HA or the HA itself are down or congested. Mobility is not supported, when the mobile does not have a HA.<o:p></o:p></= span></font></p> <p class=3DMsoNormal style=3D'margin-left:14.0pt;text-indent:-14.0pt;mso-li= st:l3 level1 lfo4'><![if !supportLists]><font size=3D1 face=3DSymbol><span style=3D'font-size:9.0pt;font-family:Symbol'><= span style=3D'mso-list:Ignore'>·<font size=3D1 face=3D"Times New Roman"><= span style=3D'font:7.0pt "Times New Roman"'>      = </span></font></span></span></font><![endif]><font size=3D2 face=3DArial><span style=3D'font-size:10.5pt;font-family:Arial'>Wh= en the mobile starts a session outside of its home network, it must use a HoA pertaining to its home network even if it engages into R/O. This requiremen= t adds air-interface overhead due to mobility headers and processing overhead= on the mobile. This upfront cost incurs even if the mobile does not move durin= g the session.<o:p></o:p></span></font></p> <p class=3DMsoNormal style=3D'margin-left:14.0pt;text-indent:-14.0pt;mso-li= st:l3 level1 lfo4'><![if !supportLists]><font size=3D1 face=3DSymbol><span style=3D'font-size:9.0pt;font-family:Symbol'><= span style=3D'mso-list:Ignore'>·<font size=3D1 face=3D"Times New Roman"><= span style=3D'font:7.0pt "Times New Roman"'>      = </span></font></span></span></font><![endif]><font size=3D2 face=3DArial><span style=3D'font-size:10.5pt;font-family:Arial'>Si= gnaling handshakes have to be conducted between mobile and HA at every mobility eve= nt.<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1= 0.5pt; font-family:Arial'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1= 0.5pt; font-family:Arial'>Currently, the Mobile IPv6 standard family forces the mo= bile to bear these disadvantages in R/O even if the HA functions are not needed. This specifically applies to scenarios where: <o:p></o:p></span></font></p> <p class=3DMsoNormal style=3D'margin-left:14.0pt;text-indent:-14.0pt;mso-li= st:l0 level1 lfo6'><![if !supportLists]><font size=3D1 face=3DSymbol><span style=3D'font-size:9.0pt;font-family:Symbol'><= span style=3D'mso-list:Ignore'>·<font size=3D1 face=3D"Times New Roman"><= span style=3D'font:7.0pt "Times New Roman"'>      = </span></font></span></span></font><![endif]><font size=3D2 face=3DArial><span style=3D'font-size:10.5pt;font-family:Arial'>Tr= affic is based on mobile-initiated requests to public servers (majority of present mobile internet traffic). The HA’s location service is not needed for= such traffic. Location service may also be provided by other means such as Dynam= ic DNS or on application layer (e.g. SIP registrar).<o:p></o:p></span></font><= /p> <p class=3DMsoNormal style=3D'margin-left:14.0pt;text-indent:-14.0pt;mso-li= st:l0 level1 lfo6'><![if !supportLists]><font size=3D1 face=3DSymbol><span style=3D'font-size:9.0pt;font-family:Symbol'><= span style=3D'mso-list:Ignore'>·<font size=3D1 face=3D"Times New Roman"><= span style=3D'font:7.0pt "Times New Roman"'>      = </span></font></span></span></font><![endif]><font size=3D2 face=3DArial><span style=3D'font-size:10.5pt;font-family:Arial'>Th= e fallback path through the HA has little value when it shares the weakest link with t= he direct path. Since the weakest link is typically the wireless link, this situation applies to all scenarios where only one air interface is availabl= e (this is the typical case rather than the exception).<o:p></o:p></span></fo= nt></p> <p class=3DMsoNormal style=3D'margin-left:14.0pt;text-indent:-14.0pt;mso-li= st:l0 level1 lfo6'><![if !supportLists]><font size=3D1 face=3DSymbol><span style=3D'font-size:9.0pt;font-family:Symbol'><= span style=3D'mso-list:Ignore'>·<font size=3D1 face=3D"Times New Roman"><= span style=3D'font:7.0pt "Times New Roman"'>      = </span></font></span></span></font><![endif]><font size=3D2 face=3DArial><span style=3D'font-size:10.5pt;font-family:Arial'>Th= e mobile may know about the correspondent’s Mobile-IPv6 support from prior ses= sions or through means external to the standard. <o:p></o:p></span></font></p> <p class=3DMsoNormal style=3D'margin-left:14.0pt;text-indent:-14.0pt;mso-li= st:l0 level1 lfo6'><![if !supportLists]><font size=3D1 face=3DSymbol><span style=3D'font-size:9.0pt;font-family:Symbol'><= span style=3D'mso-list:Ignore'>·<font size=3D1 face=3D"Times New Roman"><= span style=3D'font:7.0pt "Times New Roman"'>      = </span></font></span></span></font><![endif]><font size=3D2 face=3DArial><span style=3D'font-size:10.5pt;font-family:Arial'>Th= e mobile applies the CGA-based procedure of RFC 4866, which makes the HA’s sec= urity support for R/O unnecessary. This applies to all cases where stateless addressing is permitted. <o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1= 0.5pt; font-family:Arial'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1= 0.5pt; font-family:Arial'>To increase the flexibility and robustness of route-optimized Mobile IPv6, we propose to make the HA an *optional* rather than a *mandatory* feature, i.e. to permit operation without HA. This propo= sal requires some additional extensions to the present standard.<o:p></o:p></sp= an></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1= 0.5pt; font-family:Arial'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1= 0.5pt; font-family:Arial'>HIGH-LEVEL OUTLINE<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1= 0.5pt; font-family:Arial'>The extensions build on Enhanced Route Optimization for Mobile IPv6 (RFC 4866) to guarantee sufficient signaling security. With the absence of a HA, mobility support in R/O can be provided in the following manner:<o:p></o:p></span></font></p> <p class=3DMsoNormal style=3D'margin-left:14.0pt;text-indent:-14.0pt;mso-li= st:l1 level1 lfo8'><![if !supportLists]><font size=3D1 face=3DSymbol><span style=3D'font-size:9.0pt;font-family:Symbol'><= span style=3D'mso-list:Ignore'>·<font size=3D1 face=3D"Times New Roman"><= span style=3D'font:7.0pt "Times New Roman"'>      = </span></font></span></span></font><![endif]><font size=3D2 face=3DArial><span style=3D'font-size:10.5pt;font-family:Arial'>Th= e mobile starts the traffic session from any of its currently supported IP addresses= . The selected IP address automatically takes the function of the HoA for thi= s session. This has the advantage that conventional transport is used as long= as the mobile does not move, i.e. mobility headers and CoA-vs-HoA mapping is n= ot needed. The HoA must have been generated via CGA in compliance with RFC 486= 6. <o:p></o:p></span></font></p> <p class=3DMsoNormal style=3D'margin-left:14.0pt;text-indent:-14.0pt;mso-li= st:l1 level1 lfo8'><![if !supportLists]><font size=3D1 face=3DSymbol><span style=3D'font-size:9.0pt;font-family:Symbol'><= span style=3D'mso-list:Ignore'>·<font size=3D1 face=3D"Times New Roman"><= span style=3D'font:7.0pt "Times New Roman"'>      = </span></font></span></span></font><![endif]><font size=3D2 face=3DArial><span style=3D'font-size:10.5pt;font-family:Arial'>Th= e mobile must conduct a “home-test” from this HoA in compliance with RFC= 4866. It may conduct the home-test prior to session establishment, e.g. to find out if t= he correspondent supports the standard. <o:p></o:p></span></font></p> <p class=3DMsoNormal style=3D'margin-left:14.0pt;text-indent:-14.0pt;mso-li= st:l1 level1 lfo8'><![if !supportLists]><font size=3D1 face=3DSymbol><span style=3D'font-size:9.0pt;font-family:Symbol'><= span style=3D'mso-list:Ignore'>·<font size=3D1 face=3D"Times New Roman"><= span style=3D'font:7.0pt "Times New Roman"'>      = </span></font></span></span></font><![endif]><font size=3D2 face=3DArial><span style=3D'font-size:10.5pt;font-family:Arial'>Al= l binding update handshakes are conducted on the direct path according to RFC 4866.<o= :p></o:p></span></font></p> <p class=3DMsoNormal style=3D'margin-left:14.0pt;text-indent:-14.0pt;mso-li= st:l1 level1 lfo8'><![if !supportLists]><font size=3D1 face=3DSymbol><span style=3D'font-size:9.0pt;font-family:Symbol'><= span style=3D'mso-list:Ignore'>·<font size=3D1 face=3D"Times New Roman"><= span style=3D'font:7.0pt "Times New Roman"'>      = </span></font></span></span></font><![endif]><font size=3D2 face=3DArial><span style=3D'font-size:10.5pt;font-family:Arial'>Si= nce sessions are always started from a currently supported IP address, temporal= ly overlapping sessions may use different HoAs. A multi-homed mobile may also decide to start sessions from different simultaneously supported IP address= es. There is no principle problem here.<o:p></o:p></span></font></p> <p class=3DMsoNormal style=3D'margin-left:14.0pt;text-indent:-14.0pt;mso-li= st:l1 level1 lfo8'><![if !supportLists]><font size=3D1 face=3DSymbol><span style=3D'font-size:9.0pt;font-family:Symbol'><= span style=3D'mso-list:Ignore'>·<font size=3D1 face=3D"Times New Roman"><= span style=3D'font:7.0pt "Times New Roman"'>      = </span></font></span></span></font><![endif]><font size=3D2 face=3DArial><span style=3D'font-size:10.5pt;font-family:Arial'>Op= posed to RFC 4866, the mobile need not perform the CoA registration with the HA.<o:p= ></o:p></span></font></p> <p class=3DMsoNormal style=3D'margin-left:14.0pt;text-indent:-14.0pt;mso-li= st:l1 level1 lfo8'><![if !supportLists]><font size=3D1 face=3DSymbol><span style=3D'font-size:9.0pt;font-family:Symbol'><= span style=3D'mso-list:Ignore'>·<font size=3D1 face=3D"Times New Roman"><= span style=3D'font:7.0pt "Times New Roman"'>      = </span></font></span></span></font><![endif]><font size=3D2 face=3DArial><span style=3D'font-size:10.5pt;font-family:Arial'>Th= e mobile must be able to deregister the HoA at the correspondent in case the HoA is = not supported anymore. This ensures that the correspondent does not send packet= s to the HoA. After deregistration of the HoA, the HoA is still used by higher protocol layers of ongoing sessions. It must still be included in the mobil= ity headers for these sessions.<o:p></o:p></span></font></p> <p class=3DMsoNormal style=3D'margin-left:14.0pt;text-indent:-14.0pt;mso-li= st:l1 level1 lfo8'><![if !supportLists]><font size=3D1 face=3DSymbol><span style=3D'font-size:9.0pt;font-family:Symbol'><= span style=3D'mso-list:Ignore'>·<font size=3D1 face=3D"Times New Roman"><= span style=3D'font:7.0pt "Times New Roman"'>      = </span></font></span></span></font><![endif]><font size=3D2 face=3DArial><span style=3D'font-size:10.5pt;font-family:Arial'>Wh= en the mobile has HA support and the HA becomes temporarily unavailable, the mobil= e simply continues R/O without HA as outlined in the prior points.<o:p></o:p>= </span></font></p> <p class=3DMsoNormal style=3D'margin-left:14.0pt;text-indent:-14.0pt;mso-li= st:l1 level1 lfo8'><![if !supportLists]><font size=3D1 face=3DSymbol><span style=3D'font-size:9.0pt;font-family:Symbol'><= span style=3D'mso-list:Ignore'>·<font size=3D1 face=3D"Times New Roman"><= span style=3D'font:7.0pt "Times New Roman"'>      = </span></font></span></span></font><![endif]><font size=3D2 face=3DArial><span style=3D'font-size:10.5pt;font-family:Arial'>Th= e mobile can publish its IP address in any location service. This allows other hosts= to initiate sessions with the mobile. These sessions enjoy route-optimized mobility support only if the published IP address was generated via CGA in compliance with RFC 4866.<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1= 0.5pt; font-family:Arial'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1= 0.5pt; font-family:Arial'>OPEN ISSUES<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1= 0.5pt; font-family:Arial'>These extensions have to be made compliant with RFC 5648 (multiple CoA registration), RFC 3963 (NEMO) and others. More discussions a= re necessary.<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1= 0.5pt; font-family:Arial'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1= 0.5pt; font-family:Arial'><o:p> </o:p></span></font></p> </div> </div> </div> </body> </html> --_000_154773479ED2314980CB638A48FC44348334D271USNAVSXCHMBSA2n_-- From julienl@qualcomm.com Fri Jan 21 22:44:11 2011 Return-Path: <julienl@qualcomm.com> X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3475B3A68C8 for <mext@core3.amsl.com>; Fri, 21 Jan 2011 22:44:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.35 X-Spam-Level: X-Spam-Status: No, score=-106.35 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SrrNFZe8xquP for <mext@core3.amsl.com>; Fri, 21 Jan 2011 22:43:58 -0800 (PST) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id E83A73A68BA for <mext@ietf.org>; Fri, 21 Jan 2011 22:43:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1295678806; x=1327214806; h=from:to:cc:subject:thread-topic:thread-index:date: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: x-cr-hashedpuzzle:x-cr-puzzleid:x-originating-ip: content-type:mime-version; z=From:=20"Laganier,=20Julien"=20<julienl@qualcomm.com> |To:=20"Hampel,=20K=20Georg=20(K=20Georg)"=20<georg.hampe l@alcatel-lucent.com>,=0D=0A=09"mext@ietf.org"=20<mext@ie tf.org>|CC:=20"Klein,=20Thierry=20E=20(Thierry)"=20<thier ry.klein@alcatel-lucent.com>|Subject:=20RE:=20Support=20o f=20route=20optimization=20in=20*absence*=20of=20HA |Thread-Topic:=20Support=20of=20route=20optimization=20in =20*absence*=20of=20HA|Thread-Index:=20Acu43ZmfXvNW17TRRj u54k2cv8RwfQACxVVwAAgzMeAAIwSxMAACJO5gABhGUAA=3D|Date:=20 Sat,=2022=20Jan=202011=2006:46:45=20+0000|Message-ID:=20< 98A16B2D00B5724F81E80EF1927A029703CA27@nasanexd01e.na.qua lcomm.com>|References:=20<154773479ED2314980CB638A48FC443 48334CE4F@USNAVSXCHMBSA2.ndc.alcatel-lucent.com>=0D=0A=20 <98A16B2D00B5724F81E80EF1927A0297036BB6@nasanexd01e.na.qu alcomm.com>=0D=0A=20<154773479ED2314980CB638A48FC44348334 CFA1@USNAVSXCHMBSA2.ndc.alcatel-lucent.com>=0D=0A=20<98A1 6B2D00B5724F81E80EF1927A029703A7F6@nasanexd01e.na.qualcom m.com>=0D=0A=20<154773479ED2314980CB638A48FC44348334D271@ USNAVSXCHMBSA2.ndc.alcatel-lucent.com>|In-Reply-To:=20<15 4773479ED2314980CB638A48FC44348334D271@USNAVSXCHMBSA2.ndc .alcatel-lucent.com>|Accept-Language:=20en-US |Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|x-cr-hashedpuzzle:=20Bw5T=20D/11 =20ElWs=20F+J5=20Giv/=20HDAU=20HnlT=20Iuk6=20Kmhd=20Rw8t =20SdEZ=0D=0A=20UUHD=20U58C=20WVSS=20a5F0=0D=0A=20gzNL=3B 3=3BZwBlAG8AcgBnAC4AaABhAG0AcABlAGwAQABhAGwAYwBhAHQAZQBsA C0AbAB1AGMAZQBuAHQALgBjAG8AbQA7AG0AZQB4AHQAQABpAGUAdABmAC 4AbwByAGcAOwB0AGgAaQBlAHIAcgB5AC4AawBsAGUAaQBuAEAAYQBsAGM AYQB0AGUAbAAtAGwAdQBjAGUAbgB0AC4AYwBvAG0A=3BSosha1_v1=3B7 =3B{C857D2C0-1B5B-45D3-80E6-ABAD05B111FB}=3BagB1AGwAaQBlA G4AbABAAHEAdQBhAGwAYwBvAG0AbQAuAGMAbwBtAA=3D=3D=3BSat,=0D =0A=2022=20Jan=202011=2006:46:33=0D=0A=20GMT=3BUgBFADoAIA BTAHUAcABwAG8AcgB0ACAAbwBmACAAcgBvAHUAdABlACAAbwBwAHQAaQB tAGkAegBhAHQAaQBvAG4AIABpAG4AIAAqAGEAYgBzAGUAbgBjAGUAKgAg AG8AZgAgAEgAQQA=3D|x-cr-puzzleid:=20{C857D2C0-1B5B-45D3-8 0E6-ABAD05B111FB}|x-originating-ip:=20[199.106.114.10] |Content-Type:=20multipart/alternative=3B=0D=0A=09boundar y=3D"_000_98A16B2D00B5724F81E80EF1927A029703CA27nasanexd0 1enaqual_"|MIME-Version:=201.0; bh=cf2Fmr3yTxWJ8twrkqRyaj9XX1X7lL4uLhdgTY7dZ6U=; b=KJ2c8vUL0PX7IeqQ+XnsGqFQXIhXcjQO5+t36LhLRFP/9aBDP5jgyRkG y6ntYskGowAzbu8iydIc0z7ODek5GsRZMBCpk7uAlE+OQY0lEkrr0/+zQ qxmL8CdSnK4++1fUE5KI6c1WRW7bTjTfzW0J474VVAuJoysCepdnsTs4N U=; X-IronPort-AV: E=McAfee;i="5400,1158,6233"; a="71264885" Received: from ironmsg03-r.qualcomm.com ([172.30.46.17]) by wolverine02.qualcomm.com with ESMTP; 21 Jan 2011 22:46:45 -0800 X-IronPort-AV: E=Sophos;i="4.60,361,1291622400"; d="scan'208,217";a="44065222" Received: from nasanexhc09.na.qualcomm.com ([172.30.39.8]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/AES128-SHA; 21 Jan 2011 22:46:45 -0800 Received: from NASANEXD01E.na.qualcomm.com ([fe80::6555:8c37:4ee3:efc4]) by nasanexhc09.na.qualcomm.com ([::1]) with mapi id 14.01.0218.012; Fri, 21 Jan 2011 22:46:45 -0800 From: "Laganier, Julien" <julienl@qualcomm.com> To: "Hampel, K Georg (K Georg)" <georg.hampel@alcatel-lucent.com>, "mext@ietf.org" <mext@ietf.org> Thread-Topic: Support of route optimization in *absence* of HA Thread-Index: Acu43ZmfXvNW17TRRju54k2cv8RwfQACxVVwAAgzMeAAIwSxMAACJO5gABhGUAA= Date: Sat, 22 Jan 2011 06:46:45 +0000 Message-ID: <98A16B2D00B5724F81E80EF1927A029703CA27@nasanexd01e.na.qualcomm.com> References: <154773479ED2314980CB638A48FC44348334CE4F@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <98A16B2D00B5724F81E80EF1927A0297036BB6@nasanexd01e.na.qualcomm.com> <154773479ED2314980CB638A48FC44348334CFA1@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <98A16B2D00B5724F81E80EF1927A029703A7F6@nasanexd01e.na.qualcomm.com> <154773479ED2314980CB638A48FC44348334D271@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> In-Reply-To: <154773479ED2314980CB638A48FC44348334D271@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: Bw5T D/11 ElWs F+J5 Giv/ HDAU HnlT Iuk6 Kmhd Rw8t SdEZ UUHD U58C WVSS a5F0 gzNL; 3; ZwBlAG8AcgBnAC4AaABhAG0AcABlAGwAQABhAGwAYwBhAHQAZQBsAC0AbAB1AGMAZQBuAHQALgBjAG8AbQA7AG0AZQB4AHQAQABpAGUAdABmAC4AbwByAGcAOwB0AGgAaQBlAHIAcgB5AC4AawBsAGUAaQBuAEAAYQBsAGMAYQB0AGUAbAAtAGwAdQBjAGUAbgB0AC4AYwBvAG0A; Sosha1_v1; 7; {C857D2C0-1B5B-45D3-80E6-ABAD05B111FB}; agB1AGwAaQBlAG4AbABAAHEAdQBhAGwAYwBvAG0AbQAuAGMAbwBtAA==; Sat, 22 Jan 2011 06:46:33 GMT; UgBFADoAIABTAHUAcABwAG8AcgB0ACAAbwBmACAAcgBvAHUAdABlACAAbwBwAHQAaQBtAGkAegBhAHQAaQBvAG4AIABpAG4AIAAqAGEAYgBzAGUAbgBjAGUAKgAgAG8AZgAgAEgAQQA= x-cr-puzzleid: {C857D2C0-1B5B-45D3-80E6-ABAD05B111FB} x-originating-ip: [199.106.114.10] Content-Type: multipart/alternative; boundary="_000_98A16B2D00B5724F81E80EF1927A029703CA27nasanexd01enaqual_" MIME-Version: 1.0 Cc: "Klein, Thierry E \(Thierry\)" <thierry.klein@alcatel-lucent.com> Subject: Re: [MEXT] Support of route optimization in *absence* of HA X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG <mext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/mext> List-Post: <mailto:mext@ietf.org> List-Help: <mailto:mext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=subscribe> X-List-Received-Date: Sat, 22 Jan 2011 06:44:11 -0000 --_000_98A16B2D00B5724F81E80EF1927A029703CA27nasanexd01enaqual_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Georg, Regarding #1 I haven't decided yet I would like the group to discuss more. = The authorization of the MN to use a given HA could be asserted in a couple= of different ways, including but not limited to, a) the HA only allows cre= ation of initial binding for on-(home)-link MN, b) the HA only allows creat= ion of initial bindings for on-site MNs, i.e., CoA in a provider prefix blo= ck, and c) the HA has access to a list of CGA public keys that are authoriz= ed to create bindings. Regarding #2, if I am not mistaken, at least the 3GPP Evolved Packet System= mandates stateless address autoconfiguration for global addresses. Only th= e link-local address is generated from the IID sent by the GW. Best, --julien From: Hampel, K Georg (K Georg) [mailto:georg.hampel@alcatel-lucent.com] Sent: Friday, January 21, 2011 11:22 AM To: Laganier, Julien; Hampel, K Georg (K Georg); mext@ietf.org Cc: Klein, Thierry E (Thierry) Subject: RE: Support of route optimization in *absence* of HA Julien, Thanks for the info. I like your proposal. CGA provides cryptographic secur= ity without need for trust-relationships, PKI, pre-shared keys, etc. 1) When IPsec is replaced by CGA, MN only proves the authenticity of its Ho= A to the HA. It does not authenticate itself in absolute terms, i.e. via me= ans of strong authentication as required by IPsec or TLS. How would the HA = know that this MN is authorized to use the HA's services? 2) Do we have any idea to what extend stateless addressing is "supported"? = Does (or will) 3GPP allow stateless addressing? -Georg ________________________________ From: Laganier, Julien [mailto:julienl@qualcomm.com] Sent: Friday, January 21, 2011 1:06 PM To: Hampel, K Georg (K Georg); mext@ietf.org Cc: Klein, Thierry E (Thierry) Subject: RE: Support of route optimization in *absence* of HA Georg, Thanks for clarifying, this is what I thought. FWIW, I've tried to extend t= he RFC 4866 to secure bindings between the MN and the HA in http://tools.ie= tf.org/html/draft-laganier-mext-cga-01 --julien From: Hampel, K Georg (K Georg) [mailto:georg.hampel@alcatel-lucent.com] Sent: Thursday, January 20, 2011 5:25 PM To: Laganier, Julien; mext@ietf.org Cc: Klein, Thierry E (Thierry) Subject: RE: Support of route optimization in *absence* of HA Julien, The intentions of Homeless MIPv6 are similar to those of our proposal. In contrast to Homeless MIPv6, our proposal requires only minimal upgrades = to the present standard and implementation. (Homeless MIPv6 requires change= s to the TCP/UDP and requires AH, for instance). Here's the core idea of HA-free R/O: 1) When starting a session, the MN self-declares its current IP address= as the "HoA" for this session. This automatically means that it resides in= its "home network" and can conduct the home test directly with CN, i.e. no= home registration required. 2) All further BU/BA signaling is done directly with CN according to RF= C 4866. 3) All further signaling with HA is simply omitted. Our proposal builds on "enhanced route optimization" (RFC 4866), which prov= ides a nice security solution for R/O and creates the ground for HA-free op= eration. Little changes are required: e.g. MN must be able to deregister its HoA at = CN, etc. Regards, Georg ________________________________ From: Laganier, Julien [mailto:julienl@qualcomm.com] Sent: Thursday, January 20, 2011 4:27 PM To: Hampel, K Georg (K Georg); mext@ietf.org Cc: Klein, Thierry E (Thierry) Subject: RE: Support of route optimization in *absence* of HA Georg, Is it correct that functionally your proposal is similar to Homeless Mobile= IPv6: http://tools.ietf.org/html/draft-nikander-mobileip-homelessv6-01 Best, --julien From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of Ham= pel, K Georg (K Georg) Sent: Thursday, January 20, 2011 12:07 PM To: mext@ietf.org Cc: Hampel, K Georg (K Georg); Klein, Thierry E (Thierry) Subject: [MEXT] Support of route optimization in *absence* of HA All, We would like to add a proposal to MEXT that permits the mobile to engage i= nto route-optimization in *absence* of a home agent. Such a feature adds robustness to route optimization in case the HA is temp= orarily unavailable. Under some circumstances, route optimization *without*= HA may be beneficial for performance reasons. Our proposal requires "enhan= ced route optimization for Mobile IPv6" (RFC 4866) as pre-requisite. We would like to obtain some feedback from the MEXT community via this mail= ing list before we submit the proposal as a draft to the workgroup. For thi= s purpose, we have enclosed a high-level outline below. Thanks. Regards, Georg Hampel Networking & Networks Domain Bell Laboratories Alcatel-Lucent =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Proposal: Support of Route-Optimization in Absence of Home Agent ABSTRACT: The proposal allows the mobile to engage into route optimization (R/O) in *= absence* of a HA. This feature increases robustness when the HA becomes tem= porarily unavailable. Under some circumstances, R/O *without* HA may be ben= eficial for performance reasons. This proposal requires "enhanced route opt= imization for Mobile IPv6" (RFC 4866) as pre-requisite. MOTIVATION: In route optimization (R/O), traffic packets are directly exchanged between= hosts without passing the HA. The mobile, however, still has to interact w= ith the HA. The HA provides (1) location service, (2) a fallback path in ca= se the direct path breaks, (3) a fallback in case the correspondent does no= t support the protocol and (4) security support for R/O-related signaling (= i.e. home test). These functions come at the following cost: * Handovers may fail when the link to the HA or the HA itself are dow= n or congested. Mobility is not supported, when the mobile does not have a = HA. * When the mobile starts a session outside of its home network, it mu= st use a HoA pertaining to its home network even if it engages into R/O. Th= is requirement adds air-interface overhead due to mobility headers and proc= essing overhead on the mobile. This upfront cost incurs even if the mobile = does not move during the session. * Signaling handshakes have to be conducted between mobile and HA at = every mobility event. Currently, the Mobile IPv6 standard family forces the mobile to bear these = disadvantages in R/O even if the HA functions are not needed. This specific= ally applies to scenarios where: * Traffic is based on mobile-initiated requests to public servers (ma= jority of present mobile internet traffic). The HA's location service is no= t needed for such traffic. Location service may also be provided by other m= eans such as Dynamic DNS or on application layer (e.g. SIP registrar). * The fallback path through the HA has little value when it shares th= e weakest link with the direct path. Since the weakest link is typically th= e wireless link, this situation applies to all scenarios where only one air= interface is available (this is the typical case rather than the exception= ). * The mobile may know about the correspondent's Mobile-IPv6 support f= rom prior sessions or through means external to the standard. * The mobile applies the CGA-based procedure of RFC 4866, which makes= the HA's security support for R/O unnecessary. This applies to all cases w= here stateless addressing is permitted. To increase the flexibility and robustness of route-optimized Mobile IPv6, = we propose to make the HA an *optional* rather than a *mandatory* feature, = i.e. to permit operation without HA. This proposal requires some additional= extensions to the present standard. HIGH-LEVEL OUTLINE The extensions build on Enhanced Route Optimization for Mobile IPv6 (RFC 48= 66) to guarantee sufficient signaling security. With the absence of a HA, m= obility support in R/O can be provided in the following manner: * The mobile starts the traffic session from any of its currently sup= ported IP addresses. The selected IP address automatically takes the functi= on of the HoA for this session. This has the advantage that conventional tr= ansport is used as long as the mobile does not move, i.e. mobility headers = and CoA-vs-HoA mapping is not needed. The HoA must have been generated via = CGA in compliance with RFC 4866. * The mobile must conduct a "home-test" from this HoA in compliance w= ith RFC 4866. It may conduct the home-test prior to session establishment, = e.g. to find out if the correspondent supports the standard. * All binding update handshakes are conducted on the direct path acco= rding to RFC 4866. * Since sessions are always started from a currently supported IP add= ress, temporally overlapping sessions may use different HoAs. A multi-homed= mobile may also decide to start sessions from different simultaneously sup= ported IP addresses. There is no principle problem here. * Opposed to RFC 4866, the mobile need not perform the CoA registrati= on with the HA. * The mobile must be able to deregister the HoA at the correspondent = in case the HoA is not supported anymore. This ensures that the corresponde= nt does not send packets to the HoA. After deregistration of the HoA, the H= oA is still used by higher protocol layers of ongoing sessions. It must sti= ll be included in the mobility headers for these sessions. * When the mobile has HA support and the HA becomes temporarily unava= ilable, the mobile simply continues R/O without HA as outlined in the prior= points. * The mobile can publish its IP address in any location service. This= allows other hosts to initiate sessions with the mobile. These sessions en= joy route-optimized mobility support only if the published IP address was g= enerated via CGA in compliance with RFC 4866. OPEN ISSUES These extensions have to be made compliant with RFC 5648 (multiple CoA regi= stration), RFC 3963 (NEMO) and others. More discussions are necessary. --_000_98A16B2D00B5724F81E80EF1927A029703CA27nasanexd01enaqual_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:x=3D"urn:schemas-microsoft-com:office:excel" xmlns:p=3D"urn:schemas-m= icrosoft-com:office:powerpoint" xmlns:a=3D"urn:schemas-microsoft-com:office= :access" xmlns:dt=3D"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s=3D"= uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs=3D"urn:schemas-microsof= t-com:rowset" xmlns:z=3D"#RowsetSchema" xmlns:b=3D"urn:schemas-microsoft-co= m:office:publisher" xmlns:ss=3D"urn:schemas-microsoft-com:office:spreadshee= t" xmlns:c=3D"urn:schemas-microsoft-com:office:component:spreadsheet" xmlns= :odc=3D"urn:schemas-microsoft-com:office:odc" xmlns:oa=3D"urn:schemas-micro= soft-com:office:activation" xmlns:html=3D"http://www.w3.org/TR/REC-html40" = xmlns:q=3D"http://schemas.xmlsoap.org/soap/envelope/" xmlns:rtc=3D"http://m= icrosoft.com/officenet/conferencing" xmlns:D=3D"DAV:" xmlns:Repl=3D"http://= schemas.microsoft.com/repl/" xmlns:mt=3D"http://schemas.microsoft.com/share= point/soap/meetings/" xmlns:x2=3D"http://schemas.microsoft.com/office/excel= /2003/xml" xmlns:ppda=3D"http://www.passport.com/NameSpace.xsd" xmlns:ois= =3D"http://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir=3D"http://= schemas.microsoft.com/sharepoint/soap/directory/" xmlns:ds=3D"http://www.w3= .org/2000/09/xmldsig#" xmlns:dsp=3D"http://schemas.microsoft.com/sharepoint= /dsp" xmlns:udc=3D"http://schemas.microsoft.com/data/udc" xmlns:xsd=3D"http= ://www.w3.org/2001/XMLSchema" xmlns:sub=3D"http://schemas.microsoft.com/sha= repoint/soap/2002/1/alerts/" xmlns:ec=3D"http://www.w3.org/2001/04/xmlenc#"= xmlns:sp=3D"http://schemas.microsoft.com/sharepoint/" xmlns:sps=3D"http://= schemas.microsoft.com/sharepoint/soap/" xmlns:xsi=3D"http://www.w3.org/2001= /XMLSchema-instance" xmlns:udcs=3D"http://schemas.microsoft.com/data/udc/so= ap" xmlns:udcxf=3D"http://schemas.microsoft.com/data/udc/xmlfile" xmlns:udc= p2p=3D"http://schemas.microsoft.com/data/udc/parttopart" xmlns:wf=3D"http:/= /schemas.microsoft.com/sharepoint/soap/workflow/" xmlns:dsss=3D"http://sche= mas.microsoft.com/office/2006/digsig-setup" xmlns:dssi=3D"http://schemas.mi= crosoft.com/office/2006/digsig" xmlns:mdssi=3D"http://schemas.openxmlformat= s.org/package/2006/digital-signature" xmlns:mver=3D"http://schemas.openxmlf= ormats.org/markup-compatibility/2006" xmlns:m=3D"http://schemas.microsoft.c= om/office/2004/12/omml" xmlns:mrels=3D"http://schemas.openxmlformats.org/pa= ckage/2006/relationships" xmlns:spwp=3D"http://microsoft.com/sharepoint/web= partpages" xmlns:ex12t=3D"http://schemas.microsoft.com/exchange/services/20= 06/types" xmlns:ex12m=3D"http://schemas.microsoft.com/exchange/services/200= 6/messages" xmlns:pptsl=3D"http://schemas.microsoft.com/sharepoint/soap/Sli= deLibrary/" xmlns:spsl=3D"http://microsoft.com/webservices/SharePointPortal= Server/PublishedLinksService" xmlns:Z=3D"urn:schemas-microsoft-com:" xmlns:= st=3D"" xmlns=3D"http://www.w3.org/TR/REC-html40"> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"= > <meta name=3D"Generator" content=3D"Microsoft Word 12 (filtered medium)"> <!--[if !mso]> <style> v\:* {behavior:url(#default#VML);} o\:* {behavior:url(#default#VML);} w\:* {behavior:url(#default#VML);} .shape {behavior:url(#default#VML);} </style> <![endif]--><style> <!-- /* Font Definitions */ @font-face {font-family:"MS Mincho"; panose-1:2 2 6 9 4 2 5 8 3 4;} @font-face {font-family:"Cambria Math"; panose-1:2 4 5 3 5 4 6 3 2 4;} @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} @font-face {font-family:Tahoma; panose-1:2 11 6 4 3 5 4 4 2 4;} @font-face {font-family:"\@MS Mincho"; panose-1:2 2 6 9 4 2 5 8 3 4;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0in; margin-bottom:.0001pt; font-size:10.0pt; font-family:"Times New Roman","serif";} a:link, span.MsoHyperlink {mso-style-priority:99; color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {mso-style-priority:99; color:purple; text-decoration:underline;} span.EmailStyle17 {mso-style-type:personal; font-family:"Arial","sans-serif"; color:windowtext;} span.EmailStyle18 {mso-style-type:personal; font-family:"Calibri","sans-serif"; color:#1F497D;} span.EmailStyle19 {mso-style-type:personal; font-family:"Arial","sans-serif"; color:navy;} span.EmailStyle20 {mso-style-type:personal; font-family:"Calibri","sans-serif"; color:#1F497D;} span.EmailStyle21 {mso-style-type:personal; font-family:"Arial","sans-serif"; color:navy;} span.EmailStyle22 {mso-style-type:personal-reply; font-family:"Calibri","sans-serif"; color:#1F497D;} .MsoChpDefault {mso-style-type:export-only; font-size:10.0pt;} @page Section1 {size:8.5in 11.0in; margin:1.0in 1.25in 1.0in 1.25in;} div.Section1 {page:Section1;} /* List Definitions */ @list l0 {mso-list-id:462961695; mso-list-type:hybrid; mso-list-template-ids:-2116359956 -727278766 67698691 67698693 67698689 67= 698691 67698693 67698689 67698691 67698693;} @list l0:level1 {mso-level-number-format:bullet; mso-level-text:\F0B7; mso-level-tab-stop:-5.0pt; mso-level-number-position:left; margin-left:14.0pt; text-indent:-14.0pt; mso-ansi-font-size:9.0pt; font-family:Symbol;} @list l0:level2 {mso-level-tab-stop:1.0in; mso-level-number-position:left; text-indent:-.25in;} @list l0:level3 {mso-level-tab-stop:1.5in; mso-level-number-position:left; text-indent:-.25in;} @list l0:level4 {mso-level-tab-stop:2.0in; mso-level-number-position:left; text-indent:-.25in;} @list l0:level5 {mso-level-tab-stop:2.5in; mso-level-number-position:left; text-indent:-.25in;} @list l0:level6 {mso-level-tab-stop:3.0in; mso-level-number-position:left; text-indent:-.25in;} @list l0:level7 {mso-level-tab-stop:3.5in; mso-level-number-position:left; text-indent:-.25in;} @list l0:level8 {mso-level-tab-stop:4.0in; mso-level-number-position:left; text-indent:-.25in;} @list l0:level9 {mso-level-tab-stop:4.5in; mso-level-number-position:left; text-indent:-.25in;} @list l1 {mso-list-id:823199790; mso-list-type:hybrid; mso-list-template-ids:-198536934 -727278766 67698691 67698693 67698689 676= 98691 67698693 67698689 67698691 67698693;} @list l1:level1 {mso-level-number-format:bullet; mso-level-text:\F0B7; mso-level-tab-stop:-5.0pt; mso-level-number-position:left; margin-left:14.0pt; text-indent:-14.0pt; mso-ansi-font-size:9.0pt; font-family:Symbol;} @list l1:level2 {mso-level-tab-stop:1.0in; mso-level-number-position:left; text-indent:-.25in;} @list l1:level3 {mso-level-tab-stop:1.5in; mso-level-number-position:left; text-indent:-.25in;} @list l1:level4 {mso-level-tab-stop:2.0in; mso-level-number-position:left; text-indent:-.25in;} @list l1:level5 {mso-level-tab-stop:2.5in; mso-level-number-position:left; text-indent:-.25in;} @list l1:level6 {mso-level-tab-stop:3.0in; mso-level-number-position:left; text-indent:-.25in;} @list l1:level7 {mso-level-tab-stop:3.5in; mso-level-number-position:left; text-indent:-.25in;} @list l1:level8 {mso-level-tab-stop:4.0in; mso-level-number-position:left; text-indent:-.25in;} @list l1:level9 {mso-level-tab-stop:4.5in; mso-level-number-position:left; text-indent:-.25in;} @list l2 {mso-list-id:1836452376; mso-list-type:hybrid; mso-list-template-ids:-1378300656 -1558151418 67698713 67698715 67698703 6= 7698713 67698715 67698703 67698713 67698715;} @list l2:level1 {mso-level-text:"%1\)"; mso-level-tab-stop:.5in; mso-level-number-position:left; text-indent:-.25in;} @list l2:level2 {mso-level-tab-stop:1.0in; mso-level-number-position:left; text-indent:-.25in;} @list l2:level3 {mso-level-tab-stop:1.5in; mso-level-number-position:left; text-indent:-.25in;} @list l2:level4 {mso-level-tab-stop:2.0in; mso-level-number-position:left; text-indent:-.25in;} @list l2:level5 {mso-level-tab-stop:2.5in; mso-level-number-position:left; text-indent:-.25in;} @list l2:level6 {mso-level-tab-stop:3.0in; mso-level-number-position:left; text-indent:-.25in;} @list l2:level7 {mso-level-tab-stop:3.5in; mso-level-number-position:left; text-indent:-.25in;} @list l2:level8 {mso-level-tab-stop:4.0in; mso-level-number-position:left; text-indent:-.25in;} @list l2:level9 {mso-level-tab-stop:4.5in; mso-level-number-position:left; text-indent:-.25in;} @list l3 {mso-list-id:2000302011; mso-list-type:hybrid; mso-list-template-ids:-1553676858 -727278766 67698691 67698693 67698689 67= 698691 67698693 67698689 67698691 67698693;} @list l3:level1 {mso-level-number-format:bullet; mso-level-text:\F0B7; mso-level-tab-stop:-5.0pt; mso-level-number-position:left; margin-left:14.0pt; text-indent:-14.0pt; mso-ansi-font-size:9.0pt; font-family:Symbol;} @list l3:level2 {mso-level-tab-stop:1.0in; mso-level-number-position:left; text-indent:-.25in;} @list l3:level3 {mso-level-tab-stop:1.5in; mso-level-number-position:left; text-indent:-.25in;} @list l3:level4 {mso-level-tab-stop:2.0in; mso-level-number-position:left; text-indent:-.25in;} @list l3:level5 {mso-level-tab-stop:2.5in; mso-level-number-position:left; text-indent:-.25in;} @list l3:level6 {mso-level-tab-stop:3.0in; mso-level-number-position:left; text-indent:-.25in;} @list l3:level7 {mso-level-tab-stop:3.5in; mso-level-number-position:left; text-indent:-.25in;} @list l3:level8 {mso-level-tab-stop:4.0in; mso-level-number-position:left; text-indent:-.25in;} @list l3:level9 {mso-level-tab-stop:4.5in; mso-level-number-position:left; text-indent:-.25in;} ol {margin-bottom:0in;} ul {margin-bottom:0in;} --> </style><!--[if gte mso 9]><xml> <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext=3D"edit"> <o:idmap v:ext=3D"edit" data=3D"1" /> </o:shapelayout></xml><![endif]--> </head> <body lang=3D"EN-US" link=3D"blue" vlink=3D"purple"> <div class=3D"Section1"> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif"; color:#1F497D">Georg,<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif"; color:#1F497D"><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif"; color:#1F497D">Regarding #1 I haven’t decided yet I would like the gr= oup to discuss more. The authorization of the MN to use a given HA could be= asserted in a couple of different ways, including but not limited to, a) the HA only allows creati= on of initial binding for on-(home)-link MN, b) the HA only allows creation= of initial bindings for on-site MNs, i.e., CoA in a provider prefix block,= and c) the HA has access to a list of CGA public keys that are authorized to create bindings.<o:p></o:p></spa= n></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif"; color:#1F497D"><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif"; color:#1F497D">Regarding #2, if I am not mistaken, at least the 3GPP Evolve= d Packet System mandates stateless address autoconfiguration for global add= resses. Only the link-local address is generated from the IID sent by the GW.<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif"; color:#1F497D"><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif"; color:#1F497D">Best,<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif"; color:#1F497D"><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif"; color:#1F497D">--julien<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif"; color:#1F497D"> <o:p></o:p></span></p> <div style=3D"border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in = 4.0pt"> <div> <div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in = 0in 0in"> <p class=3D"MsoNormal"><b><span style=3D"font-family:"Tahoma",&qu= ot;sans-serif"">From:</span></b><span style=3D"font-family:"Tahom= a","sans-serif""> Hampel, K Georg (K Georg) [mailto:georg.ha= mpel@alcatel-lucent.com] <br> <b>Sent:</b> Friday, January 21, 2011 11:22 AM<br> <b>To:</b> Laganier, Julien; Hampel, K Georg (K Georg); mext@ietf.org<br> <b>Cc:</b> Klein, Thierry E (Thierry)<br> <b>Subject:</b> RE: Support of route optimization in *absence* of HA<o:p></= o:p></span></p> </div> </div> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal"><span style=3D"font-family:"Arial","s= ans-serif";color:navy">Julien,<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-family:"Arial","s= ans-serif";color:navy"><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-family:"Arial","s= ans-serif";color:navy">Thanks for the info. I like your proposal. CGA = provides cryptographic security without need for trust-relationships, PKI, = pre-shared keys, etc.<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-family:"Arial","s= ans-serif";color:navy"><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-family:"Arial","s= ans-serif";color:navy">1) When IPsec is replaced by CGA, MN only prove= s the authenticity of its HoA to the HA. It does not authenticate itself in= absolute terms, i.e. via means of strong authentication as required by IPsec or TLS. How would the HA know that this MN is authori= zed to use the HA’s services?  <o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-family:"Arial","s= ans-serif";color:navy"><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-family:"Arial","s= ans-serif";color:navy">2) Do we have any idea to what extend stateless= addressing is “supported”? Does (or will) 3GPP allow stateless= addressing?<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-family:"Arial","s= ans-serif";color:navy"><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-family:"Arial","s= ans-serif";color:navy"><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-family:"Arial","s= ans-serif";color:navy">-Georg<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-family:"Arial","s= ans-serif";color:navy"><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-family:"Arial","s= ans-serif";color:navy"><o:p> </o:p></span></p> <div> <div class=3D"MsoNormal" align=3D"center" style=3D"text-align:center"><span= style=3D"font-size:12.0pt"> <hr size=3D"2" width=3D"100%" align=3D"center"> </span></div> <p class=3D"MsoNormal"><b><span style=3D"font-family:"Tahoma",&qu= ot;sans-serif"">From:</span></b><span style=3D"font-family:"Tahom= a","sans-serif""> Laganier, Julien [mailto:julienl@qualcomm.= com] <br> <b>Sent:</b> Friday, January 21, 2011 1:06 PM<br> <b>To:</b> Hampel, K Georg (K Georg); mext@ietf.org<br> <b>Cc:</b> Klein, Thierry E (Thierry)<br> <b>Subject:</b> RE: Support of route optimization in *absence* of HA</span>= <span style=3D"font-size:12.0pt"><o:p></o:p></span></p> </div> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif"; color:#1F497D">Georg,<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif"; color:#1F497D"><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif"; color:#1F497D">Thanks for clarifying, this is what I thought. FWIW, I’= ;ve tried to extend the RFC 4866 to secure bindings between the MN and the = HA in </span><a href=3D"http://tools.ietf.org/html/draft-laganier-mext-cga-01">ht= tp://tools.ietf.org/html/draft-laganier-mext-cga-01</a><o:p></o:p></p> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif"; color:#1F497D">--julien<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif"; color:#1F497D"><o:p> </o:p></span></p> <div style=3D"border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in = 4.0pt"> <div> <div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in = 0in 0in"> <p class=3D"MsoNormal"><b><span style=3D"font-family:"Tahoma",&qu= ot;sans-serif"">From:</span></b><span style=3D"font-family:"Tahom= a","sans-serif""> Hampel, K Georg (K Georg) [mailto:georg.ha= mpel@alcatel-lucent.com] <br> <b>Sent:</b> Thursday, January 20, 2011 5:25 PM<br> <b>To:</b> Laganier, Julien; mext@ietf.org<br> <b>Cc:</b> Klein, Thierry E (Thierry)<br> <b>Subject:</b> RE: Support of route optimization in *absence* of HA<o:p></= o:p></span></p> </div> </div> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal"><span lang=3D"EN" style=3D"font-family:"Arial&q= uot;,"sans-serif"; color:navy">Julien,<o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN" style=3D"font-family:"Arial&q= uot;,"sans-serif"; color:navy"><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN" style=3D"font-family:"Arial&q= uot;,"sans-serif"; color:navy">The intentions of Homeless MIPv6 are similar to those of our pr= oposal. <o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN" style=3D"font-family:"Arial&q= uot;,"sans-serif"; color:navy"><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN" style=3D"font-family:"Arial&q= uot;,"sans-serif"; color:navy">In contrast to Homeless MIPv6, our proposal requires only minim= al upgrades to the present standard and implementation. (Homeless MIPv6 req= uires changes to the TCP/UDP and requires AH, for instance).<o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN" style=3D"font-family:"Arial&q= uot;,"sans-serif"; color:navy"><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN" style=3D"font-family:"Arial&q= uot;,"sans-serif"; color:navy">Here’s the core idea of HA-free R/O: <o:p></o:p></span></p> <p class=3D"MsoNormal" style=3D"margin-left:.5in;text-indent:-.25in;mso-lis= t:l2 level1 lfo2"> <![if !supportLists]><span lang=3D"EN" style=3D"font-family:"Arial&quo= t;,"sans-serif";color:navy"><span style=3D"mso-list:Ignore">1)<sp= an style=3D"font:7.0pt "Times New Roman"">    = ; </span></span></span><![endif]><span lang=3D"EN" style=3D"font-family:"= ;Arial","sans-serif"; color:navy">When starting a session, the MN self-declares its current IP ad= dress as the “HoA” for this session. This automatically means t= hat it resides in its “home network” and can conduct the home test directly with CN, i.e. no home registration = required.<o:p></o:p></span></p> <p class=3D"MsoNormal" style=3D"margin-left:.5in;text-indent:-.25in;mso-lis= t:l2 level1 lfo2"> <![if !supportLists]><span lang=3D"EN" style=3D"font-family:"Arial&quo= t;,"sans-serif";color:navy"><span style=3D"mso-list:Ignore">2)<sp= an style=3D"font:7.0pt "Times New Roman"">    = ; </span></span></span><![endif]><span lang=3D"EN" style=3D"font-family:"= ;Arial","sans-serif"; color:navy">All further BU/BA signaling is done directly with CN according = to RFC 4866.<o:p></o:p></span></p> <p class=3D"MsoNormal" style=3D"margin-left:.5in;text-indent:-.25in;mso-lis= t:l2 level1 lfo2"> <![if !supportLists]><span lang=3D"EN" style=3D"font-family:"Arial&quo= t;,"sans-serif";color:navy"><span style=3D"mso-list:Ignore">3)<sp= an style=3D"font:7.0pt "Times New Roman"">    = ; </span></span></span><![endif]><span lang=3D"EN" style=3D"font-family:"= ;Arial","sans-serif"; color:navy">All further signaling with HA is simply omitted.<o:p></o:p></sp= an></p> <p class=3D"MsoNormal"><span lang=3D"EN" style=3D"font-family:"Arial&q= uot;,"sans-serif"; color:navy"><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN" style=3D"font-family:"Arial&q= uot;,"sans-serif"; color:navy">Our proposal builds on “enhanced route optimization”= ; (RFC 4866), which provides a nice security solution for R/O and creates t= he ground for HA-free operation.<o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN" style=3D"font-family:"Arial&q= uot;,"sans-serif"; color:navy">Little changes are required: e.g. MN must be able to deregister= its HoA at CN, etc.<o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN" style=3D"font-family:"Arial&q= uot;,"sans-serif"; color:navy"><o:p> </o:p></span></p> <div> <p class=3D"MsoNormal"><span lang=3D"EN" style=3D"font-family:"Arial&q= uot;,"sans-serif"; color:navy">Regards,<o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN" style=3D"font-family:"Arial&q= uot;,"sans-serif"; color:navy"><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN" style=3D"font-family:"Arial&q= uot;,"sans-serif"; color:navy">Georg<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"color:navy"><o:p> </o:p></span><= /p> </div> <div> <div class=3D"MsoNormal" align=3D"center" style=3D"text-align:center"><span= style=3D"font-size:12.0pt"> <hr size=3D"2" width=3D"100%" align=3D"center"> </span></div> <p class=3D"MsoNormal"><b><span style=3D"font-family:"Tahoma",&qu= ot;sans-serif"">From:</span></b><span style=3D"font-family:"Tahom= a","sans-serif""> Laganier, Julien [mailto:julienl@qualcomm.= com] <br> <b>Sent:</b> Thursday, January 20, 2011 4:27 PM<br> <b>To:</b> Hampel, K Georg (K Georg); mext@ietf.org<br> <b>Cc:</b> Klein, Thierry E (Thierry)<br> <b>Subject:</b> RE: Support of route optimization in *absence* of HA</span>= <span style=3D"font-size:12.0pt"><o:p></o:p></span></p> </div> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif"; color:#1F497D">Georg,<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif"; color:#1F497D"><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif"; color:#1F497D">Is it correct that functionally your proposal is similar to = Homeless Mobile IPv6:<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif"; color:#1F497D"><o:p> </o:p></span></p> <p class=3D"MsoNormal"><a href=3D"http://tools.ietf.org/html/draft-nikander= -mobileip-homelessv6-01">http://tools.ietf.org/html/draft-nikander-mobileip= -homelessv6-01</a><o:p></o:p></p> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif"; color:#1F497D">Best,<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif"; color:#1F497D"><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif"; color:#1F497D">--julien<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif"; color:#1F497D"><o:p> </o:p></span></p> <div style=3D"border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in = 4.0pt"> <div> <div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in = 0in 0in"> <p class=3D"MsoNormal"><b><span style=3D"font-family:"Tahoma",&qu= ot;sans-serif"">From:</span></b><span style=3D"font-family:"Tahom= a","sans-serif""> mext-bounces@ietf.org [mailto:mext-bounces= @ietf.org] <b>On Behalf Of </b>Hampel, K Georg (K Georg)<br> <b>Sent:</b> Thursday, January 20, 2011 12:07 PM<br> <b>To:</b> mext@ietf.org<br> <b>Cc:</b> Hampel, K Georg (K Georg); Klein, Thierry E (Thierry)<br> <b>Subject:</b> [MEXT] Support of route optimization in *absence* of HA<o:p= ></o:p></span></p> </div> </div> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:"Ar= ial","sans-serif"">All,<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:"Ar= ial","sans-serif""><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:"Ar= ial","sans-serif"">We would like to add a proposal to MEXT t= hat permits the mobile to engage into route-optimization in *absence* of a = home agent. <o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:"Ar= ial","sans-serif""><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:"Ar= ial","sans-serif"">Such a feature adds robustness to route o= ptimization in case the HA is temporarily unavailable. Under some circumsta= nces, route optimization *without* HA may be beneficial for performance reasons. Our proposal requires “enhanced route optim= ization for Mobile IPv6” (RFC 4866) as pre-requisite.<o:p></o:p></spa= n></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:"Ar= ial","sans-serif""><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:"Ar= ial","sans-serif"">We would like to obtain some feedback fro= m the MEXT community via this mailing list before we submit the proposal as= a draft to the workgroup. For this purpose, we have enclosed a high-level outline below. Thanks.<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:"Ar= ial","sans-serif""><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:"Ar= ial","sans-serif"">Regards,<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-family:"Arial","s= ans-serif""><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-family:"Arial","s= ans-serif"">Georg Hampel<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-family:"Arial","s= ans-serif"">Networking & Networks Domain<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-family:"Arial","s= ans-serif"">Bell Laboratories<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-family:"Arial","s= ans-serif"">Alcatel-Lucent<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-family:"Arial","s= ans-serif"">=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= <o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-family:"Arial","s= ans-serif""><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:"Ar= ial","sans-serif"">Proposal: Support of Route-Optimization i= n Absence of Home Agent<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:"Ar= ial","sans-serif""><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:"Ar= ial","sans-serif"">ABSTRACT:<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:"Ar= ial","sans-serif"">The proposal allows the mobile to engage = into route optimization (R/O) in *absence* of a HA. This feature increases = robustness when the HA becomes temporarily unavailable. Under some circumstances, R/O *without* HA may be beneficial for performan= ce reasons. This proposal requires “enhanced route optimization for M= obile IPv6” (RFC 4866) as pre-requisite. <o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:"Ar= ial","sans-serif""><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:"Ar= ial","sans-serif"">MOTIVATION:<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:"Ar= ial","sans-serif"">In route optimization (R/O), traffic pack= ets are directly exchanged between hosts without passing the HA. The mobile= , however, still has to interact with the HA. The HA provides (1) location service, (2) a fallback path in case the direct path breaks, = (3) a fallback in case the correspondent does not support the protocol and = (4) security support for R/O-related signaling (i.e. home test). These func= tions come at the following cost:<o:p></o:p></span></p> <p class=3D"MsoNormal" style=3D"margin-left:14.0pt;text-indent:-14.0pt;mso-= list:l3 level1 lfo4"> <![if !supportLists]><span style=3D"font-size:9.0pt;font-family:Symbol"><sp= an style=3D"mso-list:Ignore">·<span style=3D"font:7.0pt "Times = New Roman"">       </span></span></span><![endif]><span style=3D"font-size:10.5pt;font-family:= "Arial","sans-serif"">Handovers may fail when the link = to the HA or the HA itself are down or congested. Mobility is not supported= , when the mobile does not have a HA.<o:p></o:p></span></p> <p class=3D"MsoNormal" style=3D"margin-left:14.0pt;text-indent:-14.0pt;mso-= list:l3 level1 lfo4"> <![if !supportLists]><span style=3D"font-size:9.0pt;font-family:Symbol"><sp= an style=3D"mso-list:Ignore">·<span style=3D"font:7.0pt "Times = New Roman"">       </span></span></span><![endif]><span style=3D"font-size:10.5pt;font-family:= "Arial","sans-serif"">When the mobile starts a session = outside of its home network, it must use a HoA pertaining to its home netwo= rk even if it engages into R/O. This requirement adds air-interface overhead due to mobility headers and processing overhead on = the mobile. This upfront cost incurs even if the mobile does not move durin= g the session.<o:p></o:p></span></p> <p class=3D"MsoNormal" style=3D"margin-left:14.0pt;text-indent:-14.0pt;mso-= list:l3 level1 lfo4"> <![if !supportLists]><span style=3D"font-size:9.0pt;font-family:Symbol"><sp= an style=3D"mso-list:Ignore">·<span style=3D"font:7.0pt "Times = New Roman"">       </span></span></span><![endif]><span style=3D"font-size:10.5pt;font-family:= "Arial","sans-serif"">Signaling handshakes have to be c= onducted between mobile and HA at every mobility event.<o:p></o:p></span></= p> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:"Ar= ial","sans-serif""><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:"Ar= ial","sans-serif"">Currently, the Mobile IPv6 standard famil= y forces the mobile to bear these disadvantages in R/O even if the HA funct= ions are not needed. This specifically applies to scenarios where: <o:p></o:p></span></p> <p class=3D"MsoNormal" style=3D"margin-left:14.0pt;text-indent:-14.0pt;mso-= list:l0 level1 lfo6"> <![if !supportLists]><span style=3D"font-size:9.0pt;font-family:Symbol"><sp= an style=3D"mso-list:Ignore">·<span style=3D"font:7.0pt "Times = New Roman"">       </span></span></span><![endif]><span style=3D"font-size:10.5pt;font-family:= "Arial","sans-serif"">Traffic is based on mobile-initia= ted requests to public servers (majority of present mobile internet traffic= ). The HA’s location service is not needed for such traffic. Location service may also be provided by other means such as Dynamic DNS o= r on application layer (e.g. SIP registrar).<o:p></o:p></span></p> <p class=3D"MsoNormal" style=3D"margin-left:14.0pt;text-indent:-14.0pt;mso-= list:l0 level1 lfo6"> <![if !supportLists]><span style=3D"font-size:9.0pt;font-family:Symbol"><sp= an style=3D"mso-list:Ignore">·<span style=3D"font:7.0pt "Times = New Roman"">       </span></span></span><![endif]><span style=3D"font-size:10.5pt;font-family:= "Arial","sans-serif"">The fallback path through the HA = has little value when it shares the weakest link with the direct path. Sinc= e the weakest link is typically the wireless link, this situation applies to all scenarios where only one air interface is availab= le (this is the typical case rather than the exception).<o:p></o:p></span><= /p> <p class=3D"MsoNormal" style=3D"margin-left:14.0pt;text-indent:-14.0pt;mso-= list:l0 level1 lfo6"> <![if !supportLists]><span style=3D"font-size:9.0pt;font-family:Symbol"><sp= an style=3D"mso-list:Ignore">·<span style=3D"font:7.0pt "Times = New Roman"">       </span></span></span><![endif]><span style=3D"font-size:10.5pt;font-family:= "Arial","sans-serif"">The mobile may know about the cor= respondent’s Mobile-IPv6 support from prior sessions or through means= external to the standard. <o:p></o:p></span></p> <p class=3D"MsoNormal" style=3D"margin-left:14.0pt;text-indent:-14.0pt;mso-= list:l0 level1 lfo6"> <![if !supportLists]><span style=3D"font-size:9.0pt;font-family:Symbol"><sp= an style=3D"mso-list:Ignore">·<span style=3D"font:7.0pt "Times = New Roman"">       </span></span></span><![endif]><span style=3D"font-size:10.5pt;font-family:= "Arial","sans-serif"">The mobile applies the CGA-based = procedure of RFC 4866, which makes the HA’s security support for R/O = unnecessary. This applies to all cases where stateless addressing is permitted. <o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:"Ar= ial","sans-serif""><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:"Ar= ial","sans-serif"">To increase the flexibility and robustnes= s of route-optimized Mobile IPv6, we propose to make the HA an *optional* r= ather than a *mandatory* feature, i.e. to permit operation without HA. This proposal requires some additional extensions to the prese= nt standard.<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:"Ar= ial","sans-serif""><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:"Ar= ial","sans-serif"">HIGH-LEVEL OUTLINE<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:"Ar= ial","sans-serif"">The extensions build on Enhanced Route Op= timization for Mobile IPv6 (RFC 4866) to guarantee sufficient signaling sec= urity. With the absence of a HA, mobility support in R/O can be provided in the following manner:<o:p></o:p></span></p> <p class=3D"MsoNormal" style=3D"margin-left:14.0pt;text-indent:-14.0pt;mso-= list:l1 level1 lfo8"> <![if !supportLists]><span style=3D"font-size:9.0pt;font-family:Symbol"><sp= an style=3D"mso-list:Ignore">·<span style=3D"font:7.0pt "Times = New Roman"">       </span></span></span><![endif]><span style=3D"font-size:10.5pt;font-family:= "Arial","sans-serif"">The mobile starts the traffic ses= sion from any of its currently supported IP addresses. The selected IP addr= ess automatically takes the function of the HoA for this session. This has the advantage that conventional transport is used as lon= g as the mobile does not move, i.e. mobility headers and CoA-vs-HoA mapping= is not needed. The HoA must have been generated via CGA in compliance with= RFC 4866. <o:p></o:p></span></p> <p class=3D"MsoNormal" style=3D"margin-left:14.0pt;text-indent:-14.0pt;mso-= list:l1 level1 lfo8"> <![if !supportLists]><span style=3D"font-size:9.0pt;font-family:Symbol"><sp= an style=3D"mso-list:Ignore">·<span style=3D"font:7.0pt "Times = New Roman"">       </span></span></span><![endif]><span style=3D"font-size:10.5pt;font-family:= "Arial","sans-serif"">The mobile must conduct a “= home-test” from this HoA in compliance with RFC 4866. It may conduct = the home-test prior to session establishment, e.g. to find out if the correspondent supports the standard. <o:p></o:p></span></p> <p class=3D"MsoNormal" style=3D"margin-left:14.0pt;text-indent:-14.0pt;mso-= list:l1 level1 lfo8"> <![if !supportLists]><span style=3D"font-size:9.0pt;font-family:Symbol"><sp= an style=3D"mso-list:Ignore">·<span style=3D"font:7.0pt "Times = New Roman"">       </span></span></span><![endif]><span style=3D"font-size:10.5pt;font-family:= "Arial","sans-serif"">All binding update handshakes are= conducted on the direct path according to RFC 4866.<o:p></o:p></span></p> <p class=3D"MsoNormal" style=3D"margin-left:14.0pt;text-indent:-14.0pt;mso-= list:l1 level1 lfo8"> <![if !supportLists]><span style=3D"font-size:9.0pt;font-family:Symbol"><sp= an style=3D"mso-list:Ignore">·<span style=3D"font:7.0pt "Times = New Roman"">       </span></span></span><![endif]><span style=3D"font-size:10.5pt;font-family:= "Arial","sans-serif"">Since sessions are always started= from a currently supported IP address, temporally overlapping sessions may= use different HoAs. A multi-homed mobile may also decide to start sessions from different simultaneously supported IP addresses. Th= ere is no principle problem here.<o:p></o:p></span></p> <p class=3D"MsoNormal" style=3D"margin-left:14.0pt;text-indent:-14.0pt;mso-= list:l1 level1 lfo8"> <![if !supportLists]><span style=3D"font-size:9.0pt;font-family:Symbol"><sp= an style=3D"mso-list:Ignore">·<span style=3D"font:7.0pt "Times = New Roman"">       </span></span></span><![endif]><span style=3D"font-size:10.5pt;font-family:= "Arial","sans-serif"">Opposed to RFC 4866, the mobile n= eed not perform the CoA registration with the HA.<o:p></o:p></span></p> <p class=3D"MsoNormal" style=3D"margin-left:14.0pt;text-indent:-14.0pt;mso-= list:l1 level1 lfo8"> <![if !supportLists]><span style=3D"font-size:9.0pt;font-family:Symbol"><sp= an style=3D"mso-list:Ignore">·<span style=3D"font:7.0pt "Times = New Roman"">       </span></span></span><![endif]><span style=3D"font-size:10.5pt;font-family:= "Arial","sans-serif"">The mobile must be able to deregi= ster the HoA at the correspondent in case the HoA is not supported anymore.= This ensures that the correspondent does not send packets to the HoA. After deregistration of the HoA, the HoA is still used by high= er protocol layers of ongoing sessions. It must still be included in the mo= bility headers for these sessions.<o:p></o:p></span></p> <p class=3D"MsoNormal" style=3D"margin-left:14.0pt;text-indent:-14.0pt;mso-= list:l1 level1 lfo8"> <![if !supportLists]><span style=3D"font-size:9.0pt;font-family:Symbol"><sp= an style=3D"mso-list:Ignore">·<span style=3D"font:7.0pt "Times = New Roman"">       </span></span></span><![endif]><span style=3D"font-size:10.5pt;font-family:= "Arial","sans-serif"">When the mobile has HA support an= d the HA becomes temporarily unavailable, the mobile simply continues R/O w= ithout HA as outlined in the prior points.<o:p></o:p></span></p> <p class=3D"MsoNormal" style=3D"margin-left:14.0pt;text-indent:-14.0pt;mso-= list:l1 level1 lfo8"> <![if !supportLists]><span style=3D"font-size:9.0pt;font-family:Symbol"><sp= an style=3D"mso-list:Ignore">·<span style=3D"font:7.0pt "Times = New Roman"">       </span></span></span><![endif]><span style=3D"font-size:10.5pt;font-family:= "Arial","sans-serif"">The mobile can publish its IP add= ress in any location service. This allows other hosts to initiate sessions = with the mobile. These sessions enjoy route-optimized mobility support only if the published IP address was generated via CGA in= compliance with RFC 4866.<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:"Ar= ial","sans-serif""><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:"Ar= ial","sans-serif"">OPEN ISSUES<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:"Ar= ial","sans-serif"">These extensions have to be made complian= t with RFC 5648 (multiple CoA registration), RFC 3963 (NEMO) and others. Mo= re discussions are necessary.<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:"Ar= ial","sans-serif""><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:"Ar= ial","sans-serif""><o:p> </o:p></span></p> </div> </div> </div> </div> </body> </html> --_000_98A16B2D00B5724F81E80EF1927A029703CA27nasanexd01enaqual_-- From behcetsarikaya@yahoo.com Mon Jan 24 11:08:24 2011 Return-Path: <behcetsarikaya@yahoo.com> X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 952A93A6AF4 for <mext@core3.amsl.com>; Mon, 24 Jan 2011 11:08:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.244 X-Spam-Level: X-Spam-Status: No, score=-2.244 tagged_above=-999 required=5 tests=[AWL=0.355, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vw5SgtYZPLhk for <mext@core3.amsl.com>; Mon, 24 Jan 2011 11:08:23 -0800 (PST) Received: from nm25-vm0.bullet.mail.sp2.yahoo.com (nm25-vm0.bullet.mail.sp2.yahoo.com [98.139.91.228]) by core3.amsl.com (Postfix) with SMTP id 23D453A6919 for <mext@ietf.org>; Mon, 24 Jan 2011 11:08:23 -0800 (PST) Received: from [98.139.91.70] by nm25.bullet.mail.sp2.yahoo.com with NNFMP; 24 Jan 2011 19:11:16 -0000 Received: from [98.139.91.34] by tm10.bullet.mail.sp2.yahoo.com with NNFMP; 24 Jan 2011 19:11:16 -0000 Received: from [127.0.0.1] by omp1034.mail.sp2.yahoo.com with NNFMP; 24 Jan 2011 19:11:16 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 180570.16403.bm@omp1034.mail.sp2.yahoo.com Received: (qmail 8349 invoked by uid 60001); 24 Jan 2011 19:11:15 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1295896275; bh=cc9OFguCkOU/Yq/ogoHl2iBnzvZXbvcUPIlYMw4XHzM=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=SA30JlwpeCjVdOvLxjP4cENjf1HkQXKIbWwxVUhHKrp78mCRPMLbrdVZYXma0K8i07fojcMicg5jC8uXhXZW2iJPX4lQ1Oe5MaYAn7CyyZ68bHHuZHjQ9EF5bjWZl58kvKaa26hK1PxBhp1GpgCA5B1aUiBE5IUMScPvVH6WQW0= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=D0pf0/J0zZf0eziecLZQDP9lF3YiaaDXt5oP/TsqM+b0wr8PGRJ8nrXQQPeAQZqmnbDyfRl42fMySPrL3JdoW1QsQWf/M4a4b9fonlQDMtycIVj6VRaELPcGpBho+aNkcWdLCDJVEe3v6ucOqp3sNfiF5HQDi93+XwGheU0xQBY=; Message-ID: <504139.8215.qm@web111413.mail.gq1.yahoo.com> X-YMail-OSG: 5TFnhUUVM1lWhE5YZVwdA6Q8nDYTeeIz7cLex699OwUPg5O Ad78- Received: from [206.16.17.212] by web111413.mail.gq1.yahoo.com via HTTP; Mon, 24 Jan 2011 11:11:14 PST X-Mailer: YahooMailRC/555 YahooMailWebService/0.8.107.285259 References: <154773479ED2314980CB638A48FC44348334CE4F@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <98A16B2D00B5724F81E80EF1927A0297036BB6@nasanexd01e.na.qualcomm.com> <154773479ED2314980CB638A48FC44348334CFA1@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <98A16B2D00B5724F81E80EF1927A029703A7F6@nasanexd01e.na.qualcomm.com> <154773479ED2314980CB638A48FC44348334D271@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <98A16B2D00B5724F81E80EF1927A029703CA27@nasanexd01e.na.qualcomm.com> Date: Mon, 24 Jan 2011 11:11:14 -0800 (PST) From: Behcet Sarikaya <behcetsarikaya@yahoo.com> To: "Laganier, Julien" <julienl@qualcomm.com>, "Hampel, K Georg \(K Georg\)" <georg.hampel@alcatel-lucent.com>, "mext@ietf.org" <mext@ietf.org> In-Reply-To: <98A16B2D00B5724F81E80EF1927A029703CA27@nasanexd01e.na.qualcomm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: "Klein, Thierry E \(Thierry\)" <thierry.klein@alcatel-lucent.com> Subject: Re: [MEXT] Support of route optimization in *absence* of HA X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya <sarikaya@ieee.org> List-Id: Mobile IPv6 EXTensions WG <mext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/mext> List-Post: <mailto:mext@ietf.org> List-Help: <mailto:mext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 24 Jan 2011 19:08:24 -0000 Wow, I was puzzled about what state addressing was.=0A=0AIt was SLAAC. Than= ks for clarifying Julien :-).=0A=0A=0A=0A=0A> =0A>Georg,=0A> =0A>Regarding = #1 I haven=E2=80=99t decided yet I would like the group to discuss more. Th= e =0A>authorization of the MN to use a given HA could be asserted in a coup= le of =0A>different ways, including but not limited to, a) the HA only all= ows creation of =0A=0A>initial binding for on-(home)-link MN, b) the HA onl= y allows creation of initial =0A>=0A>bindings for on-site MNs, i.e., CoA in= a provider prefix block, and c) the HA =0A>has access to a list of CGA pu= blic keys that are authorized to create =0Abindings.=0A> =0A>Regarding #2, = if I am not mistaken, at least the 3GPP Evolved Packet System =0A>mandates = stateless address autoconfiguration for global addresses. Only the =0A>link= -local address is generated from the IID sent by the GW.=0A> =0A>Best,=0A>= =0A>--julien=0A> =0A>From:Hampel, K Georg (K Georg) [mailto:georg.hampel@a= lcatel-lucent.com] =0A>Sent: Friday, January 21, 2011 11:22 AM=0A>To: Lagan= ier, Julien; Hampel, K Georg (K Georg); mext@ietf.org=0A>Cc: Klein, Thierry= E (Thierry)=0A>Subject: RE: Support of route optimization in *absence* of = HA=0A> =0A>Julien,=0A> =0A>Thanks for the info. I like your proposal. CGA p= rovides cryptographic security =0A>without need for trust-relationships, PK= I, pre-shared keys, etc.=0A> =0A>1) When IPsec is replaced by CGA, MN only = proves the authenticity of its HoA to =0A=0A>the HA. It does not authentica= te itself in absolute terms, i.e. via means of =0A>strong authentication a= s required by IPsec or TLS. How would the HA know that =0A>this MN is autho= rized to use the HA=E2=80=99s services? =0A> =0A>2) Do we have any idea to= what extend stateless addressing is =E2=80=9Csupported=E2=80=9D? Does =0A= =0A>(or will) 3GPP allow stateless addressing?=0A> =0A> =0A>-Georg=0A> =0A>= =0A>=0A________________________________=0A=0A>From:Laganier, Julien [mailt= o:julienl@qualcomm.com] =0A>Sent: Friday, January 21, 2011 1:06 PM=0A>To: H= ampel, K Georg (K Georg); mext@ietf.org=0A>Cc: Klein, Thierry E (Thierry)= =0A>Subject: RE: Support of route optimization in *absence* of HA=0A> =0A>G= eorg,=0A> =0A>Thanks for clarifying, this is what I thought. FWIW, I=E2=80= =99ve tried to extend the =0A>RFC 4866 to secure bindings between the MN an= d the HA in =0A>http://tools.ietf.org/html/draft-laganier-mext-cga-01=0A> = =0A>--julien=0A> =0A>From:Hampel, K Georg (K Georg) [mailto:georg.hampel@al= catel-lucent.com] =0A>Sent: Thursday, January 20, 2011 5:25 PM=0A>To: Lagan= ier, Julien; mext@ietf.org=0A>Cc: Klein, Thierry E (Thierry)=0A>Subject: RE= : Support of route optimization in *absence* of HA=0A> =0A>Julien,=0A> =0A>= The intentions of Homeless MIPv6 are similar to those of our proposal. =0A>= =0A>In contrast to Homeless MIPv6, our proposal requires only minimal upgr= ades to =0A>the present standard and implementation. (Homeless MIPv6 requir= es changes to the =0A>=0A>TCP/UDP and requires AH, for instance).=0A> =0A>= Here=E2=80=99s the core idea of HA-free R/O: =0A>1) When starting a ses= sion, the MN self-declares its current IP address as =0A>the =E2=80=9CHoA= =E2=80=9D for this session. This automatically means that it resides in its= =0A>=E2=80=9Chome network=E2=80=9D and can conduct the home test directly= with CN, i.e. no home =0A>registration required.=0A>2) All further BU/= BA signaling is done directly with CN according to RFC =0A>4866.=0A>3) = All further signaling with HA is simply omitted.=0A> =0A>Our proposal build= s on =E2=80=9Cenhanced route optimization=E2=80=9D (RFC 4866), which provid= es =0A=0A>a nice security solution for R/O and creates the ground for HA-fr= ee operation.=0A>Little changes are required: e.g. MN must be able to dereg= ister its HoA at CN, =0A>etc.=0A> =0A>Regards,=0A> =0A>Georg=0A> =0A>=0A___= _____________________________=0A=0A>From:Laganier, Julien [mailto:julienl@q= ualcomm.com] =0A>Sent: Thursday, January 20, 2011 4:27 PM=0A>To: Hampel, K = Georg (K Georg); mext@ietf.org=0A>Cc: Klein, Thierry E (Thierry)=0A>Subject= : RE: Support of route optimization in *absence* of HA=0A> =0A>Georg,=0A> = =0A>Is it correct that functionally your proposal is similar to Homeless Mo= bile =0A>IPv6:=0A> =0A>http://tools.ietf.org/html/draft-nikander-mobileip-h= omelessv6-01=0A> =0A>Best,=0A> =0A>--julien=0A> =0A>From:mext-bounces@ietf.= org [mailto:mext-bounces@ietf.org] On Behalf Of Hampel, K =0A>=0A>Georg (K = Georg)=0A>Sent: Thursday, January 20, 2011 12:07 PM=0A>To: mext@ietf.org=0A= >Cc: Hampel, K Georg (K Georg); Klein, Thierry E (Thierry)=0A>Subject: [MEX= T] Support of route optimization in *absence* of HA=0A> =0A>All,=0A> =0A>We= would like to add a proposal to MEXT that permits the mobile to engage int= o =0A>route-optimization in *absence* of a home agent. =0A>=0A> =0A>Such a = feature adds robustness to route optimization in case the HA is =0A>tempora= rily unavailable. Under some circumstances, route optimization *without* = =0A=0A>HA may be beneficial for performance reasons. Our proposal requires= =E2=80=9Cenhanced =0A>route optimization for Mobile IPv6=E2=80=9D (RFC 486= 6) as pre-requisite.=0A> =0A>We would like to obtain some feedback from the= MEXT community via this mailing =0A>list before we submit the proposal as = a draft to the workgroup. For this =0A>purpose, we have enclosed a high-le= vel outline below. Thanks.=0A> =0A>Regards,=0A> =0A>Georg Hampel=0A>Network= ing & Networks Domain=0A>Bell Laboratories=0A>Alcatel-Lucent=0A>=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A> =0A>Proposal: Support = of Route-Optimization in Absence of Home Agent=0A> =0A>ABSTRACT:=0A>The pro= posal allows the mobile to engage into route optimization (R/O) in =0A>*abs= ence* of a HA. This feature increases robustness when the HA becomes =0A>te= mporarily unavailable. Under some circumstances, R/O *without* HA may be = =0A>beneficial for performance reasons. This proposal requires =E2=80=9Cenh= anced route =0A>optimization for Mobile IPv6=E2=80=9D (RFC 4866) as pre-req= uisite. =0A>=0A> =0A>MOTIVATION:=0A>In route optimization (R/O), traffic pa= ckets are directly exchanged between =0A>hosts without passing the HA. The = mobile, however, still has to interact with =0A>the HA. The HA provides (1= ) location service, (2) a fallback path in case the =0A>direct path breaks,= (3) a fallback in case the correspondent does not support =0A>the protocol= and (4) security support for R/O-related signaling (i.e. home =0A>test). T= hese functions come at the following cost:=0A>=C2=B7 Handovers may fa= il when the link to the HA or the HA itself are down or =0A=0A>congested. M= obility is not supported, when the mobile does not have a HA.=0A>=C2=B7 = When the mobile starts a session outside of its home network, it must = =0A>use a HoA pertaining to its home network even if it engages into R/O. T= his =0A>requirement adds air-interface overhead due to mobility headers an= d processing =0A=0A>overhead on the mobile. This upfront cost incurs even i= f the mobile does not =0A>move during the session.=0A>=C2=B7 Signalin= g handshakes have to be conducted between mobile and HA at every =0A>=0A>mo= bility event.=0A> =0A>Currently, the Mobile IPv6 standard family forces the= mobile to bear these =0A>disadvantages in R/O even if the HA functions are= not needed. This specifically =0A=0A>applies to scenarios where: =0A>=0A>= =C2=B7 Traffic is based on mobile-initiated requests to public server= s =0A>(majority of present mobile internet traffic). The HA=E2=80=99s locat= ion service is not =0A=0A>needed for such traffic. Location service may al= so be provided by other means =0A>such as Dynamic DNS or on application lay= er (e.g. SIP registrar).=0A>=C2=B7 The fallback path through the HA h= as little value when it shares the =0A>weakest link with the direct path. S= ince the weakest link is typically the =0A>wireless link, this situation a= pplies to all scenarios where only one air =0A>interface is available (this= is the typical case rather than the exception).=0A>=C2=B7 The mobile= may know about the correspondent=E2=80=99s Mobile-IPv6 support from =0A>pr= ior sessions or through means external to the standard. =0A>=0A>=C2=B7 = The mobile applies the CGA-based procedure of RFC 4866, which makes the = =0A=0A>HA=E2=80=99s security support for R/O unnecessary. This applies to a= ll cases where =0A>stateless addressing is permitted. =0A>=0A> =0A>To incr= ease the flexibility and robustness of route-optimized Mobile IPv6, we =0A>= propose to make the HA an *optional* rather than a *mandatory* feature, i.e= . to =0A=0A>permit operation without HA. This proposal requires some addit= ional extensions =0A=0A>to the present standard.=0A> =0A>HIGH-LEVEL OUTLINE= =0A>The extensions build on Enhanced Route Optimization for Mobile IPv6 (RF= C 4866) =0A>to guarantee sufficient signaling security. With the absence of= a HA, mobility =0A>support in R/O can be provided in the following manner= :=0A>=C2=B7 The mobile starts the traffic session from any of its cur= rently =0A>supported IP addresses. The selected IP address automatically ta= kes the function =0A>=0A>of the HoA for this session. This has the advanta= ge that conventional transport =0A>=0A>is used as long as the mobile does n= ot move, i.e. mobility headers and =0A>CoA-vs-HoA mapping is not needed. Th= e HoA must have been generated via CGA in =0A>compliance with RFC 4866. =0A= >=0A>=C2=B7 The mobile must conduct a =E2=80=9Chome-test=E2=80=9D fro= m this HoA in compliance with =0A>RFC 4866. It may conduct the home-test pr= ior to session establishment, e.g. to =0A>find out if the correspondent su= pports the standard. =0A>=0A>=C2=B7 All binding update handshakes are= conducted on the direct path according =0A>=0A>to RFC 4866.=0A>=C2=B7 = Since sessions are always started from a currently supported IP address, = =0A>=0A>temporally overlapping sessions may use different HoAs. A multi-hom= ed mobile may =0A>=0A>also decide to start sessions from different simulta= neously supported IP =0A>addresses. There is no principle problem here.=0A>= =C2=B7 Opposed to RFC 4866, the mobile need not perform the CoA regis= tration =0A>with the HA.=0A>=C2=B7 The mobile must be able to deregis= ter the HoA at the correspondent in =0A>case the HoA is not supported anymo= re. This ensures that the correspondent does =0A=0A>not send packets to th= e HoA. After deregistration of the HoA, the HoA is still =0A=0A>used by hig= her protocol layers of ongoing sessions. It must still be included in =0A>= =0A>the mobility headers for these sessions.=0A>=C2=B7 When the mobil= e has HA support and the HA becomes temporarily =0A>unavailable, the mobile= simply continues R/O without HA as outlined in the prior =0A>=0A>points.= =0A>=C2=B7 The mobile can publish its IP address in any location serv= ice. This =0A>allows other hosts to initiate sessions with the mobile. Thes= e sessions enjoy =0A>route-optimized mobility support only if the publishe= d IP address was generated =0A>=0A>via CGA in compliance with RFC 4866.=0A>= =0A>OPEN ISSUES=0A>These extensions have to be made compliant with RFC 564= 8 (multiple CoA =0A>registration), RFC 3963 (NEMO) and others. More discuss= ions are necessary.=0A> =0A> =0A=0A=0A From marcelo@it.uc3m.es Mon Jan 24 11:31:07 2011 Return-Path: <marcelo@it.uc3m.es> X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4621B28C0E0 for <mext@core3.amsl.com>; Mon, 24 Jan 2011 11:31:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.558 X-Spam-Level: X-Spam-Status: No, score=-106.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cJ22KckZd6UT for <mext@core3.amsl.com>; Mon, 24 Jan 2011 11:31:05 -0800 (PST) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id AF2F928C0D8 for <mext@ietf.org>; Mon, 24 Jan 2011 11:31:05 -0800 (PST) X-uc3m-safe: yes Received: from marcelo-bagnulos-macbook-pro-2.local (86.31.18.95.dynamic.jazztel.es [95.18.31.86]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp01.uc3m.es (Postfix) with ESMTP id 49435C27E0F for <mext@ietf.org>; Mon, 24 Jan 2011 20:33:59 +0100 (CET) Message-ID: <4D3DD426.6080107@it.uc3m.es> Date: Mon, 24 Jan 2011 20:33:58 +0100 From: marcelo bagnulo braun <marcelo@it.uc3m.es> User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; es-ES; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: mext <mext@ietf.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.5.0.1024-17914.000 Subject: [MEXT] Call for WG adoption of I-D: draft-korhonen-mext-mip6-altsec X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG <mext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/mext> List-Post: <mailto:mext@ietf.org> List-Help: <mailto:mext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 24 Jan 2011 19:31:07 -0000 The ID has had 3 reviews as we require. So, we are now ready to ask the WG if they think we should adopt the document. Please express your opinion before monday 31st jan. Reviews can be found: The I-D: draft-korhonen-mext-mip6-altsec-06 has been reviewed by: 1. Jan Zorz http://www.ietf.org/mail-archive/web/mext/current/msg04489.html 2. Domagoz Premec http://www.ietf.org/mail-archive/web/mext/current/msg04457.html 3. Ryuji Wakikawa http://www.ietf.org/mail-archive/web/mext/current/msg04470.html From jan@go6.si Mon Jan 24 12:44:40 2011 Return-Path: <jan@go6.si> X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6EE543A695F for <mext@core3.amsl.com>; Mon, 24 Jan 2011 12:44:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3q6dgespHEzj for <mext@core3.amsl.com>; Mon, 24 Jan 2011 12:44:39 -0800 (PST) Received: from ipv6.go6.si (go6.si [IPv6:2a02:e8:0:1::babe:face]) by core3.amsl.com (Postfix) with ESMTP id 1896B3A692C for <mext@ietf.org>; Mon, 24 Jan 2011 12:44:38 -0800 (PST) Received: from jan-mac.local (unknown [IPv6:2001:470:d422:1:1293:e9ff:fe07:182c]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jan) by ipv6.go6.si (Postfix) with ESMTP id E5030237803C for <mext@ietf.org>; Mon, 24 Jan 2011 21:47:32 +0100 (CET) Message-ID: <4D3DE564.30505@go6.si> Date: Mon, 24 Jan 2011 21:47:32 +0100 From: "Jan Zorz @ go6.si" <jan@go6.si> User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: mext@ietf.org References: <4D3DD426.6080107@it.uc3m.es> In-Reply-To: <4D3DD426.6080107@it.uc3m.es> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [MEXT] Call for WG adoption of I-D: draft-korhonen-mext-mip6-altsec X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG <mext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/mext> List-Post: <mailto:mext@ietf.org> List-Help: <mailto:mext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 24 Jan 2011 20:44:40 -0000 On 1/24/11 8:33 PM, marcelo bagnulo braun wrote: > The ID has had 3 reviews as we require. > So, we are now ready to ask the WG if they think we should adopt the > document. > > Please express your opinion before monday 31st jan. Well, I think this I-D should go forward as it solves some issues with current thinking of mobile part of the stack, and it has an implementation, that works fine. Regards, Jan Zorz go6.si From arno@natisbad.org Mon Jan 24 13:55:21 2011 Return-Path: <arno@natisbad.org> X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 343323A698E for <mext@core3.amsl.com>; Mon, 24 Jan 2011 13:55:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AaAi5xFlY0w0 for <mext@core3.amsl.com>; Mon, 24 Jan 2011 13:55:19 -0800 (PST) Received: from copper.chdir.org (copper.chdir.org [88.191.97.87]) by core3.amsl.com (Postfix) with ESMTP id 170B33A698D for <mext@ietf.org>; Mon, 24 Jan 2011 13:55:19 -0800 (PST) Received: from small (unknown [IPv6:2a01:e35:2efc:86d0:216:eaff:feec:ae14]) by copper.chdir.org (Postfix) with ESMTPSA id A0C4E450053; Mon, 24 Jan 2011 22:58:10 +0100 (CET) X-Hashcash: 1:20:110124:marcelo@it.uc3m.es::MuAAQR+5TAO/ciid:00000000000000000000000000000000000000000001Ryu X-Hashcash: 1:20:110124:julien.laganier.ietf@googlemail.com::u0qaMQtrfVeKH9mO:0000000000000000000000000031Zo From: arno@natisbad.org (Arnaud Ebalard) To: "Jan Zorz \@ go6.si" <jan@go6.si> References: <4D3DD426.6080107@it.uc3m.es> <4D3DE564.30505@go6.si> X-PGP-Key-URL: http://natisbad.org/arno@natisbad.org.asc X-Fingerprint: D3A5 B68A 839B 38A5 815A 781B B77C 0748 A7AE 341B X-Hashcash: 1:20:110124:mext@ietf.org::sAyjZku9h0vNJFbH:0000336l X-Hashcash: 1:20:110124:jan@go6.si::Avs3FrEml9efDXeK:000000051Bw Date: Mon, 24 Jan 2011 22:58:09 +0100 Message-ID: <878vyarmku.fsf@natisbad.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Julien Laganier <julien.laganier.ietf@googlemail.com>, mext@ietf.org Subject: Re: [MEXT] Call for WG adoption of I-D: draft-korhonen-mext-mip6-altsec X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG <mext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/mext> List-Post: <mailto:mext@ietf.org> List-Help: <mailto:mext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 24 Jan 2011 21:55:21 -0000 Hi, "Jan Zorz @ go6.si" <jan@go6.si> writes: > On 1/24/11 8:33 PM, marcelo bagnulo braun wrote: >> The ID has had 3 reviews as we require. >> So, we are now ready to ask the WG if they think we should adopt the >> document. >> >> Please express your opinion before monday 31st jan. > > Well, I think this I-D should go forward as it solves some issues with > current thinking of mobile part of the stack, and it has an > implementation, that works fine. At some point, I wanted to test the implementation initially provided on http://dsmipv6-tls.nokia.net but when I went to the site later it was no more available (current status). BTW, I was told the source code would be available for review but never got a pointer. Which implementation are you using? Regarding the draft, I am *against* adopting the document for the reasons already given on the list a while ago (see [1]): > Honestly, I *must* be missing something. To make a parallel, to me, you > are trying to change a screwdriver into a hammer. And I still don't > understand why. > > If you simply need a solution to encapsulate IPv4 or IPv6 packets over > UDP with an ESP header, why don't you simply use an IKE daemon with > support for MOBIKE? Or if you really want to use TLS for key > provisioning, some DTLS-based VPN? > > Here, you combine UDP-encapsulated IPsec packet format for NAT-T (copy > and paste of ESP rfc, iirc), replace usual IKE for key establishment by a > *custom* protocol based on TLS and HTTP to provide key provisioning. There > is even a section (5.6.5) to provide a mapping between TLS ciphersuites > and the algs used to protect IPsec-piggybacked packets. To me, what the draft describes is a patchwork based on MIPv6, ESP and TLS. Instead of building on top of those protocols (read modularity and interoperability), it reuses (hijacks) various blocks of associated standards in a non-modular way. For instance, one has to reimplement ESP in userspace to support the protocol. Additionally, it does not support RO. Cheers, a+ [1]: http://permalink.gmane.org/gmane.ietf.mip6/10368 From Basavaraj.Patil@nokia.com Mon Jan 24 14:00:58 2011 Return-Path: <Basavaraj.Patil@nokia.com> X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 881623A696F for <mext@core3.amsl.com>; Mon, 24 Jan 2011 14:00:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.543 X-Spam-Level: X-Spam-Status: No, score=-103.543 tagged_above=-999 required=5 tests=[AWL=-0.944, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HmpPaPGWVSO4 for <mext@core3.amsl.com>; Mon, 24 Jan 2011 14:00:57 -0800 (PST) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by core3.amsl.com (Postfix) with ESMTP id 54BF53A69A6 for <mext@ietf.org>; Mon, 24 Jan 2011 14:00:57 -0800 (PST) Received: from vaebh101.NOE.Nokia.com (vaebh101.europe.nokia.com [10.160.244.22]) by mgw-sa01.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p0OM3mGr008802; Tue, 25 Jan 2011 00:03:48 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 25 Jan 2011 00:03:36 +0200 Received: from 008-AM1MMR1-002.mgdnok.nokia.com (65.54.30.57) by NOK-am1MHUB-01.mgdnok.nokia.com (65.54.30.5) with Microsoft SMTP Server (TLS) id 8.2.255.0; Mon, 24 Jan 2011 23:03:36 +0100 Received: from 008-AM1MPN1-004.mgdnok.nokia.com ([169.254.5.187]) by 008-AM1MMR1-002.mgdnok.nokia.com ([65.54.30.57]) with mapi; Mon, 24 Jan 2011 23:03:35 +0100 From: <Basavaraj.Patil@nokia.com> To: <arno@natisbad.org>, <jan@go6.si> Thread-Topic: [MEXT] Call for WG adoption of I-D: draft-korhonen-mext-mip6-altsec Thread-Index: AQHLvBKLTg4gV2FeYUKwegM9zkfBrQ== Date: Mon, 24 Jan 2011 22:03:33 +0000 Message-ID: <C963527A.D013%basavaraj.patil@nokia.com> In-Reply-To: <878vyarmku.fsf@natisbad.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.101115 Content-Type: text/plain; charset="us-ascii" Content-ID: <a0e04f7a-e4b8-4f3b-a673-35d82f358f83> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 24 Jan 2011 22:03:36.0627 (UTC) FILETIME=[8CB49830:01CBBC12] X-Nokia-AV: Clean Cc: julien.laganier.ietf@googlemail.com, mext@ietf.org Subject: Re: [MEXT] Call for WG adoption of I-D: draft-korhonen-mext-mip6-altsec X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG <mext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/mext> List-Post: <mailto:mext@ietf.org> List-Help: <mailto:mext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 24 Jan 2011 22:00:58 -0000 Inline: On 1/24/11 3:58 PM, "ext Arnaud Ebalard" <arno@natisbad.org> wrote: > >To me, what the draft describes is a patchwork based on MIPv6, ESP and >TLS. Instead of building on top of those protocols (read modularity and >interoperability), it reuses (hijacks) various blocks of associated >standards in a non-modular way. For instance, one has to reimplement ESP >in userspace to support the protocol. We are specifying an encapsulation method in the I-D. To say that one has to reimplement ESP in userspace is incorrect. We are reusing TLS which is widely implemented today. I do not see a problem with reuse. > >Additionally, it does not support RO. We are adding RO support to the spec. It is not a big deal to support RO between MIP6 nodes. Securing the RO signaling messages between the MN-HA uses the same method used for the BU/BAck messages. -Raj > >Cheers, > >a+ > >[1]: http://permalink.gmane.org/gmane.ietf.mip6/10368 >_______________________________________________ >MEXT mailing list >MEXT@ietf.org >https://www.ietf.org/mailman/listinfo/mext From behcetsarikaya@yahoo.com Mon Jan 24 16:02:52 2011 Return-Path: <behcetsarikaya@yahoo.com> X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 28E0B3A69C3 for <mext@core3.amsl.com>; Mon, 24 Jan 2011 16:02:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.255 X-Spam-Level: X-Spam-Status: No, score=-2.255 tagged_above=-999 required=5 tests=[AWL=0.344, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zm6dHPfKWwLw for <mext@core3.amsl.com>; Mon, 24 Jan 2011 16:02:50 -0800 (PST) Received: from nm5-vm0.bullet.mail.sp2.yahoo.com (nm5-vm0.bullet.mail.sp2.yahoo.com [98.139.91.204]) by core3.amsl.com (Postfix) with SMTP id 9203C3A69C1 for <mext@ietf.org>; Mon, 24 Jan 2011 16:02:50 -0800 (PST) Received: from [98.139.91.65] by nm5.bullet.mail.sp2.yahoo.com with NNFMP; 25 Jan 2011 00:05:43 -0000 Received: from [98.139.91.53] by tm5.bullet.mail.sp2.yahoo.com with NNFMP; 25 Jan 2011 00:05:43 -0000 Received: from [127.0.0.1] by omp1053.mail.sp2.yahoo.com with NNFMP; 25 Jan 2011 00:05:43 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 946202.90252.bm@omp1053.mail.sp2.yahoo.com Received: (qmail 13847 invoked by uid 60001); 25 Jan 2011 00:05:43 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1295913943; bh=/fEMZ7PWWuBt/VUF1p8ZBEEU+MZaafab4Ge/+OfijOo=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=fl8eLyxWpBunCwNi5oxePpvOsi+2TNGyuaAJxpSs3HclzguY07gzQtlvciJ+6Bb6PR3ZlYrCTjSUo3g4KBITESO4tYLKM139QYhi3x/JLEnrL/J+grOTTqY9iNJiZw3T+AmYS5jTWFMg+wzez2jQ+O98h/VjGjRdGxo6VmXWKR8= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=c2G32yR+XyBO/rbFSLbwia51I16DGFEkYHyoWr9fI65UcpA+FNjjfvzatooZ5YnKDaRskaNAgU908h/hVUx1I25wJaQhEZRg6sPOHphipq2rdjJCx8VltxBaNAm7w4iJ7wAvrntZfHEe27lAT4HwCI372NGcW4gIUPvoWuil99A=; Message-ID: <556277.9581.qm@web111406.mail.gq1.yahoo.com> X-YMail-OSG: eDcFYuUVM1nwiO2M1FJpnKfj9tLY0x_95Z7gg41PcWr96tj jZ6252SzpAIybGAYyzQuiv0sg28qn4JQG_MdBjbue8Bx7ZQD8HFdW6DR7iuD MFlmvytXvLEjodUuxjjvZKI8JuSzvq0wlx2fctgpCVEzIz4Cz7llvdTUx8fi yE5zhO6OHUDuN2.qDEHLg6Q3MhdwoskeGi_umbq0mI.Cira.6mVpgzhMs9fn VTtPpoqW3ROzcMttbv7cuHgSLdZdTgA_1fZxliO8PxZ4SewlESomiEHiTM8I fGXXob7H9eJO7dBf_dlJIUB3cTc9H6RX2jy14cHkrp.8mn6pgXC8CMyFOVM0 6YNUOADuhzRBly5xleq9LEk_4DyaTBVGK1wx1OMkEBm3rafKW5JPFuChTqKn X_ruzI_ZtS_JM Received: from [206.16.17.212] by web111406.mail.gq1.yahoo.com via HTTP; Mon, 24 Jan 2011 16:05:43 PST X-Mailer: YahooMailRC/555 YahooMailWebService/0.8.107.285259 References: <4D3DD426.6080107@it.uc3m.es> <4D3DE564.30505@go6.si> Date: Mon, 24 Jan 2011 16:05:43 -0800 (PST) From: Behcet Sarikaya <behcetsarikaya@yahoo.com> To: "Jan Zorz @ go6.si" <jan@go6.si>, mext@ietf.org In-Reply-To: <4D3DE564.30505@go6.si> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [MEXT] Call for WG adoption of I-D: draft-korhonen-mext-mip6-altsec X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya <sarikaya@ieee.org> List-Id: Mobile IPv6 EXTensions WG <mext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/mext> List-Post: <mailto:mext@ietf.org> List-Help: <mailto:mext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 25 Jan 2011 00:02:52 -0000 ----- Original Message ---- > From: "Jan Zorz @ go6.si" <jan@go6.si> > To: mext@ietf.org > Sent: Mon, January 24, 2011 2:47:32 PM > Subject: Re: [MEXT] Call for WG adoption of I-D: >draft-korhonen-mext-mip6-altsec > > On 1/24/11 8:33 PM, marcelo bagnulo braun wrote: > > The ID has had 3 reviews as we require. > > So, we are now ready to ask the WG if they think we should adopt the > > document. > > > > Please express your opinion before monday 31st jan. > > Well, I think this I-D should go forward as it solves some issues with current >thinking of mobile part of the stack, and it has an implementation, that works >fine. > +1 --behcet From jan@go6.si Tue Jan 25 00:03:49 2011 Return-Path: <jan@go6.si> X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A6AE3A6A84 for <mext@core3.amsl.com>; Tue, 25 Jan 2011 00:03:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id odOfTumBkQ6u for <mext@core3.amsl.com>; Tue, 25 Jan 2011 00:03:48 -0800 (PST) Received: from ipv6.go6.si (go6.si [IPv6:2a02:e8:0:1::babe:face]) by core3.amsl.com (Postfix) with ESMTP id 9F2BC3A6A7C for <mext@ietf.org>; Tue, 25 Jan 2011 00:03:48 -0800 (PST) Received: from jan-mac.local (unknown [IPv6:2001:470:d422:1:1293:e9ff:fe07:182c]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jan) by ipv6.go6.si (Postfix) with ESMTP id AA6B4237803C; Tue, 25 Jan 2011 09:05:59 +0100 (CET) Message-ID: <4D3E8466.2030702@go6.si> Date: Tue, 25 Jan 2011 09:05:58 +0100 From: "Jan Zorz @ go6.si" <jan@go6.si> User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Arnaud Ebalard <arno@natisbad.org> References: <4D3DD426.6080107@it.uc3m.es> <4D3DE564.30505@go6.si> <878vyarmku.fsf@natisbad.org> In-Reply-To: <878vyarmku.fsf@natisbad.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Julien Laganier <julien.laganier.ietf@googlemail.com>, mext@ietf.org Subject: Re: [MEXT] Call for WG adoption of I-D: draft-korhonen-mext-mip6-altsec X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG <mext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/mext> List-Post: <mailto:mext@ietf.org> List-Help: <mailto:mext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 25 Jan 2011 08:03:49 -0000 On 1/24/11 10:58 PM, Arnaud Ebalard wrote: > Additionally, it does not support RO. Currently weakest point of the draft. This needs to be changed, as I pointed out in review. Regards, Jan From arno@natisbad.org Tue Jan 25 00:16:02 2011 Return-Path: <arno@natisbad.org> X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 045B03A6B76 for <mext@core3.amsl.com>; Tue, 25 Jan 2011 00:16:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m-32XFNojhWm for <mext@core3.amsl.com>; Tue, 25 Jan 2011 00:15:50 -0800 (PST) Received: from copper.chdir.org (copper.chdir.org [88.191.97.87]) by core3.amsl.com (Postfix) with ESMTP id 52D2D3A6A87 for <mext@ietf.org>; Tue, 25 Jan 2011 00:15:49 -0800 (PST) Received: from enough (unknown [IPv6:2001:7a8:1161:20:baac:6fff:fe41:5166]) by copper.chdir.org (Postfix) with ESMTPSA id EE005450053; Tue, 25 Jan 2011 09:18:40 +0100 (CET) From: arno@natisbad.org (Arnaud Ebalard) To: <Basavaraj.Patil@nokia.com> References: <C963527A.D013%basavaraj.patil@nokia.com> X-PGP-Key-URL: http://natisbad.org/arno@natisbad.org.asc X-Fingerprint: D3A5 B68A 839B 38A5 815A 781B B77C 0748 A7AE 341B X-Hashcash: 1:20:110125:mext@ietf.org::7fiWXaN+m+69Scg9:000016YT X-Hashcash: 1:20:110125:basavaraj.patil@nokia.com::m3hBHu6g09pqrb/A:0000000000000000000000000000000000001RQi X-Hashcash: 1:20:110125:julien.laganier.ietf@googlemail.com::EYVWdF9ynKoYeNb4:000000000000000000000000002X/5 X-Hashcash: 1:20:110125:jan@go6.si::/MmuPc5y4UrocE3I:000000056u6 Date: Tue, 25 Jan 2011 09:13:15 +0100 In-Reply-To: <C963527A.D013%basavaraj.patil@nokia.com> (Basavaraj Patil's message of "Mon, 24 Jan 2011 22:03:33 +0000") Message-ID: <87fwshv1t0.fsf@natisbad.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: julien.laganier.ietf@googlemail.com, jan@go6.si, mext@ietf.org Subject: Re: [MEXT] Call for WG adoption of I-D: draft-korhonen-mext-mip6-altsec X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG <mext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/mext> List-Post: <mailto:mext@ietf.org> List-Help: <mailto:mext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 25 Jan 2011 08:16:02 -0000 Hi, <Basavaraj.Patil@nokia.com> writes: > Inline: > > On 1/24/11 3:58 PM, "ext Arnaud Ebalard" <arno@natisbad.org> wrote: > >> >>To me, what the draft describes is a patchwork based on MIPv6, ESP and >>TLS. Instead of building on top of those protocols (read modularity and >>interoperability), it reuses (hijacks) various blocks of associated >>standards in a non-modular way. For instance, one has to reimplement ESP >>in userspace to support the protocol. > > We are specifying an encapsulation method in the I-D. To say that one has > to reimplement ESP in userspace is incorrect. Then please explain how one is supposed to get the format described in section 6.4 which is *explicitly* borrowed from RFC 4303 w/o reimplementing it in userspace? Or are you pushing SP and SA in order to reuse what is already implemented in the IPsec stack? BTW, is the packages/sources of your implementation still available somewhere? I expected the patches to be pushed upstream at some point. Cheers, a+ From georg.hampel@alcatel-lucent.com Tue Jan 25 07:42:02 2011 Return-Path: <georg.hampel@alcatel-lucent.com> X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F2693A67EF for <mext@core3.amsl.com>; Tue, 25 Jan 2011 07:42:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XzG42FxLeTPF for <mext@core3.amsl.com>; Tue, 25 Jan 2011 07:41:48 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id 65C743A67EA for <mext@ietf.org>; Tue, 25 Jan 2011 07:41:47 -0800 (PST) Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id p0PFibEA023522 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 25 Jan 2011 09:44:40 -0600 (CST) Received: from USNAVSXCHHUB03.ndc.alcatel-lucent.com (usnavsxchhub03.ndc.alcatel-lucent.com [135.3.39.112]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p0PFib5K028998 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 25 Jan 2011 09:44:37 -0600 Received: from USNAVSXCHMBSA2.ndc.alcatel-lucent.com ([135.3.39.127]) by USNAVSXCHHUB03.ndc.alcatel-lucent.com ([135.3.39.112]) with mapi; Tue, 25 Jan 2011 09:44:37 -0600 From: "Hampel, K Georg (K Georg)" <georg.hampel@alcatel-lucent.com> To: "Laganier, Julien" <julienl@qualcomm.com>, "mext@ietf.org" <mext@ietf.org> Date: Tue, 25 Jan 2011 09:44:35 -0600 Thread-Topic: Support of route optimization in *absence* of HA Thread-Index: Acu43ZmfXvNW17TRRju54k2cv8RwfQACxVVwAAgzMeAAIwSxMAACJO5gABhGUAAAqMagMA== Message-ID: <154773479ED2314980CB638A48FC4434833B9F67@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> References: <154773479ED2314980CB638A48FC44348334CE4F@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <98A16B2D00B5724F81E80EF1927A0297036BB6@nasanexd01e.na.qualcomm.com> <154773479ED2314980CB638A48FC44348334CFA1@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <98A16B2D00B5724F81E80EF1927A029703A7F6@nasanexd01e.na.qualcomm.com> <154773479ED2314980CB638A48FC44348334D271@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <98A16B2D00B5724F81E80EF1927A029703CA27@nasanexd01e.na.qualcomm.com> In-Reply-To: <98A16B2D00B5724F81E80EF1927A029703CA27@nasanexd01e.na.qualcomm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_154773479ED2314980CB638A48FC4434833B9F67USNAVSXCHMBSA2n_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.9 Cc: "Klein, Thierry E \(Thierry\)" <thierry.klein@alcatel-lucent.com> Subject: Re: [MEXT] Support of route optimization in *absence* of HA X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG <mext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/mext> List-Post: <mailto:mext@ietf.org> List-Help: <mailto:mext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 25 Jan 2011 15:42:02 -0000 --_000_154773479ED2314980CB638A48FC4434833B9F67USNAVSXCHMBSA2n_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, Based on feedback and further thoughts, I propose to permit HA-free operati= on on a more general level, i.e. for ALL R/O-solutions that permit return-r= outability procedure WITHOUT participation of the HA. Among those are curre= ntly: - RFC 4866: Enhanced R/O for MIPv6 - RFC 4449: Securing MIPv6 R/O using static shared key - draft-ebalard-mext-ipsec-ro-01: Mobile IPv6 IPsec Route Optimization (IRO= ) Note that HA-free R/O was already anticipated by RFC 4651 (A Taxonomy and A= nalysis of Enhancements to Mobile IPv6 Route Optimization). I think it woul= d add substantial value to MIPv6. RFC 4651 says: 2.4. Robustness Enhancements Route Optimization could conceptually enable continued communications during periods of temporary home-agent unavailability. The protocol defined in RFC 3775 does not achieve this independence, however, as the home agent plays an active role in the return-routability procedure. Appropriate enhancements could increase the independence from the home agent and thus enable robust Route Optimization even in the absence of the home agent. Regards, - Georg ________________________________ From: Laganier, Julien [mailto:julienl@qualcomm.com] Sent: Saturday, January 22, 2011 1:47 AM To: Hampel, K Georg (K Georg); mext@ietf.org Cc: Klein, Thierry E (Thierry) Subject: RE: Support of route optimization in *absence* of HA Georg, Regarding #1 I haven't decided yet I would like the group to discuss more. = The authorization of the MN to use a given HA could be asserted in a couple= of different ways, including but not limited to, a) the HA only allows cre= ation of initial binding for on-(home)-link MN, b) the HA only allows creat= ion of initial bindings for on-site MNs, i.e., CoA in a provider prefix blo= ck, and c) the HA has access to a list of CGA public keys that are authoriz= ed to create bindings. Regarding #2, if I am not mistaken, at least the 3GPP Evolved Packet System= mandates stateless address autoconfiguration for global addresses. Only th= e link-local address is generated from the IID sent by the GW. Best, --julien From: Hampel, K Georg (K Georg) [mailto:georg.hampel@alcatel-lucent.com] Sent: Friday, January 21, 2011 11:22 AM To: Laganier, Julien; Hampel, K Georg (K Georg); mext@ietf.org Cc: Klein, Thierry E (Thierry) Subject: RE: Support of route optimization in *absence* of HA Julien, Thanks for the info. I like your proposal. CGA provides cryptographic secur= ity without need for trust-relationships, PKI, pre-shared keys, etc. 1) When IPsec is replaced by CGA, MN only proves the authenticity of its Ho= A to the HA. It does not authenticate itself in absolute terms, i.e. via me= ans of strong authentication as required by IPsec or TLS. How would the HA = know that this MN is authorized to use the HA's services? 2) Do we have any idea to what extend stateless addressing is "supported"? = Does (or will) 3GPP allow stateless addressing? -Georg ________________________________ From: Laganier, Julien [mailto:julienl@qualcomm.com] Sent: Friday, January 21, 2011 1:06 PM To: Hampel, K Georg (K Georg); mext@ietf.org Cc: Klein, Thierry E (Thierry) Subject: RE: Support of route optimization in *absence* of HA Georg, Thanks for clarifying, this is what I thought. FWIW, I've tried to extend t= he RFC 4866 to secure bindings between the MN and the HA in http://tools.ie= tf.org/html/draft-laganier-mext-cga-01 --julien From: Hampel, K Georg (K Georg) [mailto:georg.hampel@alcatel-lucent.com] Sent: Thursday, January 20, 2011 5:25 PM To: Laganier, Julien; mext@ietf.org Cc: Klein, Thierry E (Thierry) Subject: RE: Support of route optimization in *absence* of HA Julien, The intentions of Homeless MIPv6 are similar to those of our proposal. In contrast to Homeless MIPv6, our proposal requires only minimal upgrades = to the present standard and implementation. (Homeless MIPv6 requires change= s to the TCP/UDP and requires AH, for instance). Here's the core idea of HA-free R/O: 1) When starting a session, the MN self-declares its current IP addre= ss as the "HoA" for this session. This automatically means that it resides = in its "home network" and can conduct the home test directly with CN, i.e. = no home registration required. 2) All further BU/BA signaling is done directly with CN according to = RFC 4866. 3) All further signaling with HA is simply omitted. Our proposal builds on "enhanced route optimization" (RFC 4866), which prov= ides a nice security solution for R/O and creates the ground for HA-free op= eration. Little changes are required: e.g. MN must be able to deregister its HoA at = CN, etc. Regards, Georg ________________________________ From: Laganier, Julien [mailto:julienl@qualcomm.com] Sent: Thursday, January 20, 2011 4:27 PM To: Hampel, K Georg (K Georg); mext@ietf.org Cc: Klein, Thierry E (Thierry) Subject: RE: Support of route optimization in *absence* of HA Georg, Is it correct that functionally your proposal is similar to Homeless Mobile= IPv6: http://tools.ietf.org/html/draft-nikander-mobileip-homelessv6-01 Best, --julien From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of Ham= pel, K Georg (K Georg) Sent: Thursday, January 20, 2011 12:07 PM To: mext@ietf.org Cc: Hampel, K Georg (K Georg); Klein, Thierry E (Thierry) Subject: [MEXT] Support of route optimization in *absence* of HA All, We would like to add a proposal to MEXT that permits the mobile to engage i= nto route-optimization in *absence* of a home agent. Such a feature adds robustness to route optimization in case the HA is temp= orarily unavailable. Under some circumstances, route optimization *without*= HA may be beneficial for performance reasons. Our proposal requires "enhan= ced route optimization for Mobile IPv6" (RFC 4866) as pre-requisite. We would like to obtain some feedback from the MEXT community via this mail= ing list before we submit the proposal as a draft to the workgroup. For thi= s purpose, we have enclosed a high-level outline below. Thanks. Regards, Georg Hampel Networking & Networks Domain Bell Laboratories Alcatel-Lucent =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Proposal: Support of Route-Optimization in Absence of Home Agent ABSTRACT: The proposal allows the mobile to engage into route optimization (R/O) in *= absence* of a HA. This feature increases robustness when the HA becomes tem= porarily unavailable. Under some circumstances, R/O *without* HA may be ben= eficial for performance reasons. This proposal requires "enhanced route opt= imization for Mobile IPv6" (RFC 4866) as pre-requisite. MOTIVATION: In route optimization (R/O), traffic packets are directly exchanged between= hosts without passing the HA. The mobile, however, still has to interact w= ith the HA. The HA provides (1) location service, (2) a fallback path in ca= se the direct path breaks, (3) a fallback in case the correspondent does no= t support the protocol and (4) security support for R/O-related signaling (= i.e. home test). These functions come at the following cost: * Handovers may fail when the link to the HA or the HA itself are dow= n or congested. Mobility is not supported, when the mobile does not have a = HA. * When the mobile starts a session outside of its home network, it mu= st use a HoA pertaining to its home network even if it engages into R/O. Th= is requirement adds air-interface overhead due to mobility headers and proc= essing overhead on the mobile. This upfront cost incurs even if the mobile = does not move during the session. * Signaling handshakes have to be conducted between mobile and HA at = every mobility event. Currently, the Mobile IPv6 standard family forces the mobile to bear these = disadvantages in R/O even if the HA functions are not needed. This specific= ally applies to scenarios where: * Traffic is based on mobile-initiated requests to public servers (ma= jority of present mobile internet traffic). The HA's location service is no= t needed for such traffic. Location service may also be provided by other m= eans such as Dynamic DNS or on application layer (e.g. SIP registrar). * The fallback path through the HA has little value when it shares th= e weakest link with the direct path. Since the weakest link is typically th= e wireless link, this situation applies to all scenarios where only one air= interface is available (this is the typical case rather than the exception= ). * The mobile may know about the correspondent's Mobile-IPv6 support f= rom prior sessions or through means external to the standard. * The mobile applies the CGA-based procedure of RFC 4866, which makes= the HA's security support for R/O unnecessary. This applies to all cases w= here stateless addressing is permitted. To increase the flexibility and robustness of route-optimized Mobile IPv6, = we propose to make the HA an *optional* rather than a *mandatory* feature, = i.e. to permit operation without HA. This proposal requires some additional= extensions to the present standard. HIGH-LEVEL OUTLINE The extensions build on Enhanced Route Optimization for Mobile IPv6 (RFC 48= 66) to guarantee sufficient signaling security. With the absence of a HA, m= obility support in R/O can be provided in the following manner: * The mobile starts the traffic session from any of its currently sup= ported IP addresses. The selected IP address automatically takes the functi= on of the HoA for this session. This has the advantage that conventional tr= ansport is used as long as the mobile does not move, i.e. mobility headers = and CoA-vs-HoA mapping is not needed. The HoA must have been generated via = CGA in compliance with RFC 4866. * The mobile must conduct a "home-test" from this HoA in compliance w= ith RFC 4866. It may conduct the home-test prior to session establishment, = e.g. to find out if the correspondent supports the standard. * All binding update handshakes are conducted on the direct path acco= rding to RFC 4866. * Since sessions are always started from a currently supported IP add= ress, temporally overlapping sessions may use different HoAs. A multi-homed= mobile may also decide to start sessions from different simultaneously sup= ported IP addresses. There is no principle problem here. * Opposed to RFC 4866, the mobile need not perform the CoA registrati= on with the HA. * The mobile must be able to deregister the HoA at the correspondent = in case the HoA is not supported anymore. This ensures that the corresponde= nt does not send packets to the HoA. After deregistration of the HoA, the H= oA is still used by higher protocol layers of ongoing sessions. It must sti= ll be included in the mobility headers for these sessions. * When the mobile has HA support and the HA becomes temporarily unava= ilable, the mobile simply continues R/O without HA as outlined in the prior= points. * The mobile can publish its IP address in any location service. This= allows other hosts to initiate sessions with the mobile. These sessions en= joy route-optimized mobility support only if the published IP address was g= enerated via CGA in compliance with RFC 4866. OPEN ISSUES These extensions have to be made compliant with RFC 5648 (multiple CoA regi= stration), RFC 3963 (NEMO) and others. More discussions are necessary. --_000_154773479ED2314980CB638A48FC4434833B9F67USNAVSXCHMBSA2n_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:x=3D"urn:schemas-microsoft-com:office:excel" xmlns:p=3D"urn:schemas-m= icrosoft-com:office:powerpoint" xmlns:a=3D"urn:schemas-microsoft-com:office= :access" xmlns:dt=3D"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s=3D"= uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs=3D"urn:schemas-microsof= t-com:rowset" xmlns:z=3D"#RowsetSchema" xmlns:b=3D"urn:schemas-microsoft-co= m:office:publisher" xmlns:ss=3D"urn:schemas-microsoft-com:office:spreadshee= t" xmlns:c=3D"urn:schemas-microsoft-com:office:component:spreadsheet" xmlns= :odc=3D"urn:schemas-microsoft-com:office:odc" xmlns:oa=3D"urn:schemas-micro= soft-com:office:activation" xmlns:html=3D"http://www.w3.org/TR/REC-html40" = xmlns:q=3D"http://schemas.xmlsoap.org/soap/envelope/" xmlns:rtc=3D"http://m= icrosoft.com/officenet/conferencing" xmlns:D=3D"DAV:" xmlns:Repl=3D"http://= schemas.microsoft.com/repl/" xmlns:mt=3D"http://schemas.microsoft.com/share= point/soap/meetings/" xmlns:x2=3D"http://schemas.microsoft.com/office/excel= /2003/xml" xmlns:ppda=3D"http://www.passport.com/NameSpace.xsd" xmlns:ois= =3D"http://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir=3D"http://= schemas.microsoft.com/sharepoint/soap/directory/" xmlns:ds=3D"http://www.w3= .org/2000/09/xmldsig#" xmlns:dsp=3D"http://schemas.microsoft.com/sharepoint= /dsp" xmlns:udc=3D"http://schemas.microsoft.com/data/udc" xmlns:xsd=3D"http= ://www.w3.org/2001/XMLSchema" xmlns:sub=3D"http://schemas.microsoft.com/sha= repoint/soap/2002/1/alerts/" xmlns:ec=3D"http://www.w3.org/2001/04/xmlenc#"= xmlns:sp=3D"http://schemas.microsoft.com/sharepoint/" xmlns:sps=3D"http://= schemas.microsoft.com/sharepoint/soap/" xmlns:xsi=3D"http://www.w3.org/2001= /XMLSchema-instance" xmlns:udcs=3D"http://schemas.microsoft.com/data/udc/so= ap" xmlns:udcxf=3D"http://schemas.microsoft.com/data/udc/xmlfile" xmlns:udc= p2p=3D"http://schemas.microsoft.com/data/udc/parttopart" xmlns:st=3D"" = xmlns:st1=3D"urn:schemas-microsoft-com:office:smarttags" xmlns=3D"http://ww= w.w3.org/TR/REC-html40" xmlns:ns0=3D"http://schemas.microsoft.com/sharepoint/soap/workflow/" xmlns:ns1=3D"http://schemas.microsoft.com/office/2006/digsig-setup" xmlns:ns2=3D"http://schemas.microsoft.com/office/2006/digsig" xmlns:ns3=3D"http://schemas.openxmlformats.org/package/2006/digital-signatu= re" xmlns:ns4=3D"http://schemas.openxmlformats.org/markup-compatibility/2006" xmlns:ns5=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns:ns6=3D"http://schemas.openxmlformats.org/package/2006/relationships" xmlns:ns7=3D"http://microsoft.com/sharepoint/webpartpages" xmlns:ns8=3D"http://schemas.microsoft.com/exchange/services/2006/types" xmlns:ns9=3D"http://schemas.microsoft.com/exchange/services/2006/messages" xmlns:ns10=3D"http://schemas.microsoft.com/sharepoint/soap/SlideLibrary/" xmlns:ns11=3D"http://microsoft.com/webservices/SharePointPortalServer/Publi= shedLinksService" xmlns:ns12=3D"urn:schemas-microsoft-com:"> <head> <meta http-equiv=3DContent-Type content=3D"text/html; charset=3Dus-ascii"> <meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)"> <!--[if !mso]> <style> v\:* {behavior:url(#default#VML);} o\:* {behavior:url(#default#VML);} w\:* {behavior:url(#default#VML);} .shape {behavior:url(#default#VML);} </style> <![endif]--><o:SmartTagType namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags" name=3D"State"= /> <o:SmartTagType namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags" name=3D"City"/> <o:SmartTagType namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags" name=3D"place"/> <o:SmartTagType namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags" name=3D"PersonName"/> <!--[if !mso]> <style> st1\:*{behavior:url(#default#ieooui) } </style> <![endif]--> <style> <!--a:link {mso-style-priority:99;} span.MSOHYPERLINK {mso-style-priority:99;} a:visited {mso-style-priority:99;} span.MSOHYPERLINKFOLLOWED {mso-style-priority:99;} /* Font Definitions */ @font-face {font-family:Wingdings; panose-1:5 0 0 0 0 0 0 0 0 0;} @font-face {font-family:SimSun; panose-1:2 1 6 0 3 1 1 1 1 1;} @font-face {font-family:Tahoma; panose-1:2 11 6 4 3 5 4 4 2 4;} @font-face {font-family:"\@SimSun"; panose-1:2 1 6 0 3 1 1 1 1 1;} @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0pt; margin-bottom:.0001pt; font-size:10.0pt; font-family:"Times New Roman";} a:link, span.MsoHyperlink {color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {color:purple; text-decoration:underline;} pre {margin:0pt; margin-bottom:.0001pt; font-size:10.0pt; font-family:"Courier New";} span.EmailStyle17 {mso-style-type:personal; font-family:Arial; color:windowtext;} span.EmailStyle18 {mso-style-type:personal; font-family:Calibri; color:#1F497D;} span.EmailStyle19 {mso-style-type:personal; font-family:Arial; color:navy;} span.EmailStyle20 {mso-style-type:personal; font-family:Calibri; color:#1F497D;} span.EmailStyle21 {mso-style-type:personal; font-family:Arial; color:navy;} span.EmailStyle22 {mso-style-type:personal; font-family:Calibri; color:#1F497D;} span.EmailStyle23 {mso-style-type:personal-reply; font-family:Arial; color:navy;} @page Section1 {size:612.0pt 792.0pt; margin:72.0pt 90.0pt 72.0pt 90.0pt;} div.Section1 {page:Section1;} /* List Definitions */ @list l0 {mso-list-id:462961695; mso-list-type:hybrid; mso-list-template-ids:-2116359956 -727278766 67698691 67698693 67698689 67= 698691 67698693 67698689 67698691 67698693;} @list l0:level1 {mso-level-number-format:bullet; mso-level-text:\F0B7; mso-level-tab-stop:-5.0pt; mso-level-number-position:left; margin-left:14.0pt; text-indent:-14.0pt; mso-ansi-font-size:9.0pt; font-family:Symbol;} @list l0:level2 {mso-level-tab-stop:72.0pt; mso-level-number-position:left; text-indent:-18.0pt;} @list l0:level3 {mso-level-tab-stop:108.0pt; mso-level-number-position:left; text-indent:-18.0pt;} @list l0:level4 {mso-level-tab-stop:144.0pt; mso-level-number-position:left; text-indent:-18.0pt;} @list l0:level5 {mso-level-tab-stop:180.0pt; mso-level-number-position:left; text-indent:-18.0pt;} @list l0:level6 {mso-level-tab-stop:216.0pt; mso-level-number-position:left; text-indent:-18.0pt;} @list l0:level7 {mso-level-tab-stop:252.0pt; mso-level-number-position:left; text-indent:-18.0pt;} @list l0:level8 {mso-level-tab-stop:288.0pt; mso-level-number-position:left; text-indent:-18.0pt;} @list l0:level9 {mso-level-tab-stop:324.0pt; mso-level-number-position:left; text-indent:-18.0pt;} @list l1 {mso-list-id:823199790; mso-list-type:hybrid; mso-list-template-ids:-198536934 -727278766 67698691 67698693 67698689 676= 98691 67698693 67698689 67698691 67698693;} @list l1:level1 {mso-level-number-format:bullet; mso-level-text:\F0B7; mso-level-tab-stop:-5.0pt; mso-level-number-position:left; margin-left:14.0pt; text-indent:-14.0pt; mso-ansi-font-size:9.0pt; font-family:Symbol;} @list l1:level2 {mso-level-tab-stop:72.0pt; mso-level-number-position:left; text-indent:-18.0pt;} @list l1:level3 {mso-level-tab-stop:108.0pt; mso-level-number-position:left; text-indent:-18.0pt;} @list l1:level4 {mso-level-tab-stop:144.0pt; mso-level-number-position:left; text-indent:-18.0pt;} @list l1:level5 {mso-level-tab-stop:180.0pt; mso-level-number-position:left; text-indent:-18.0pt;} @list l1:level6 {mso-level-tab-stop:216.0pt; mso-level-number-position:left; text-indent:-18.0pt;} @list l1:level7 {mso-level-tab-stop:252.0pt; mso-level-number-position:left; text-indent:-18.0pt;} @list l1:level8 {mso-level-tab-stop:288.0pt; mso-level-number-position:left; text-indent:-18.0pt;} @list l1:level9 {mso-level-tab-stop:324.0pt; mso-level-number-position:left; text-indent:-18.0pt;} @list l2 {mso-list-id:1757825405; mso-list-type:hybrid; mso-list-template-ids:207244514 489067024 67698691 67698693 67698689 67698= 691 67698693 67698689 67698691 67698693;} @list l2:level1 {mso-level-start-at:6; mso-level-number-format:bullet; mso-level-text:-; mso-level-tab-stop:36.0pt; mso-level-number-position:left; text-indent:-18.0pt; font-family:Arial; mso-fareast-font-family:SimSun;} @list l3 {mso-list-id:1836452376; mso-list-type:hybrid; mso-list-template-ids:-1378300656 -1558151418 67698713 67698715 67698703 6= 7698713 67698715 67698703 67698713 67698715;} @list l3:level1 {mso-level-text:"%1\)"; mso-level-tab-stop:36.0pt; mso-level-number-position:left; text-indent:-18.0pt;} @list l3:level2 {mso-level-tab-stop:72.0pt; mso-level-number-position:left; text-indent:-18.0pt;} @list l3:level3 {mso-level-tab-stop:108.0pt; mso-level-number-position:left; text-indent:-18.0pt;} @list l3:level4 {mso-level-tab-stop:144.0pt; mso-level-number-position:left; text-indent:-18.0pt;} @list l3:level5 {mso-level-tab-stop:180.0pt; mso-level-number-position:left; text-indent:-18.0pt;} @list l3:level6 {mso-level-tab-stop:216.0pt; mso-level-number-position:left; text-indent:-18.0pt;} @list l3:level7 {mso-level-tab-stop:252.0pt; mso-level-number-position:left; text-indent:-18.0pt;} @list l3:level8 {mso-level-tab-stop:288.0pt; mso-level-number-position:left; text-indent:-18.0pt;} @list l3:level9 {mso-level-tab-stop:324.0pt; mso-level-number-position:left; text-indent:-18.0pt;} @list l4 {mso-list-id:2000302011; mso-list-type:hybrid; mso-list-template-ids:-1553676858 -727278766 67698691 67698693 67698689 67= 698691 67698693 67698689 67698691 67698693;} @list l4:level1 {mso-level-number-format:bullet; mso-level-text:\F0B7; mso-level-tab-stop:-5.0pt; mso-level-number-position:left; margin-left:14.0pt; text-indent:-14.0pt; mso-ansi-font-size:9.0pt; font-family:Symbol;} @list l4:level2 {mso-level-tab-stop:72.0pt; mso-level-number-position:left; text-indent:-18.0pt;} @list l4:level3 {mso-level-tab-stop:108.0pt; mso-level-number-position:left; text-indent:-18.0pt;} @list l4:level4 {mso-level-tab-stop:144.0pt; mso-level-number-position:left; text-indent:-18.0pt;} @list l4:level5 {mso-level-tab-stop:180.0pt; mso-level-number-position:left; text-indent:-18.0pt;} @list l4:level6 {mso-level-tab-stop:216.0pt; mso-level-number-position:left; text-indent:-18.0pt;} @list l4:level7 {mso-level-tab-stop:252.0pt; mso-level-number-position:left; text-indent:-18.0pt;} @list l4:level8 {mso-level-tab-stop:288.0pt; mso-level-number-position:left; text-indent:-18.0pt;} @list l4:level9 {mso-level-tab-stop:324.0pt; mso-level-number-position:left; text-indent:-18.0pt;} ol {margin-bottom:0pt;} ul {margin-bottom:0pt;} --> </style> <!--[if gte mso 9]><xml> <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext=3D"edit"> <o:idmap v:ext=3D"edit" data=3D"1" /> </o:shapelayout></xml><![endif]--> </head> <body lang=3DEN-US link=3Dblue vlink=3Dpurple> <div class=3DSection1> <div> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style= =3D'font-size: 10.0pt;font-family:Arial;color:navy'>All,<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style= =3D'font-size: 10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style= =3D'font-size: 10.0pt;font-family:Arial;color:navy'>Based on feedback and further thoughts= , I propose to permit HA-free operation on a more general level, i.e. for ALL R/O-solutions that permit return-routability procedure WITHOUT participatio= n of the HA. Among those are currently:<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style= =3D'font-size: 10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style= =3D'font-size: 10.0pt;font-family:Arial;color:navy'>- RFC 4866: Enhanced R/O for MIPv6</sp= an></font><font color=3Dnavy face=3DArial><span lang=3DEN style=3D'font-family:Arial;color:= navy'><o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span lang=3D= EN style=3D'font-size:10.0pt;font-family:Arial;color:navy'><o:p> </o:p></= span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span lang=3D= EN style=3D'font-size:10.0pt;font-family:Arial;color:navy'>- </span></font><fo= nt color=3Dnavy face=3DArial><span style=3D'font-family:Arial;color:navy'>RFC = 4449: Securing MIPv6 R/O using static shared key</span></font><font color=3Dnavy face=3DArial><span lang=3DEN style=3D'font-family:Arial;color:navy'><o:p></= o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span lang=3D= EN style=3D'font-size:10.0pt;font-family:Arial;color:navy'><o:p> </o:p></= span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span lang=3D= EN style=3D'font-size:10.0pt;font-family:Arial;color:navy'>- draft-ebalard-mex= t-ipsec-ro-01: Mobile IPv6 IPsec Route Optimization (IRO)<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span lang=3D= EN style=3D'font-size:10.0pt;font-family:Arial;color:navy'><o:p> </o:p></= span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span lang=3D= EN style=3D'font-size:10.0pt;font-family:Arial;color:navy'><o:p> </o:p></= span></font></p> <p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 color=3Dn= avy face=3DArial><span lang=3DEN style=3D'font-size:10.0pt;font-family:Arial;co= lor:navy'>Note that HA-free R/O was already anticipated by RFC 4651 (</span></font><font color=3Dnavy face=3DArial><span style=3D'font-family:Arial;color:navy'>A Ta= xonomy and Analysis of Enhancements to Mobile IPv6 Route Optimization). I think it wou= ld add substantial value to MIPv6. RFC 4651 says:<o:p></o:p></span></font></p> <pre><font size=3D2 color=3Dnavy face=3DArial><span style=3D'font-size:10.0= pt; font-family:Arial;color:navy'><o:p> </o:p></span></font></pre><pre><fo= nt size=3D2 color=3Dnavy face=3DArial><span style=3D'font-size:10.0pt;font-fam= ily:Arial; color:navy'>2.4. Robustness Enhancements<o:p></o:p></span></font></pre><pre= ><font size=3D2 color=3Dnavy face=3DArial><span style=3D'font-size:10.0pt;font-fam= ily:Arial; color:navy'><o:p> </o:p></span></font></pre><pre><font size=3D2 color= =3Dnavy face=3DArial><span style=3D'font-size:10.0pt;font-family:Arial;color:navy'>=    Route Optimization could conceptually enable continued communi= cations<o:p></o:p></span></font></pre><pre><font size=3D2 color=3Dnavy face=3DArial><span style=3D'font-size:10.0pt;font-fam= ily:Arial; color:navy'>   during periods of temporary home-agent unavailabil= ity.  The protocol<o:p></o:p></span></font></pre><pre><font size=3D2 color=3Dnavy face=3DArial><span style=3D'font-size:10.0pt;font-fam= ily:Arial; color:navy'>   defined in RFC 3775 does not achieve this independ= ence, however, as<o:p></o:p></span></font></pre><pre><font size=3D2 color=3Dnavy face=3DArial><span style=3D'font-size:10.0pt;font-fam= ily:Arial; color:navy'>   the home agent plays an active role in the return-= routability<o:p></o:p></span></font></pre><pre><font size=3D2 color=3Dnavy face=3DArial><span style=3D'font-size:10.0pt;font-fam= ily:Arial; color:navy'>   procedure.  Appropriate enhancements could in= crease the independence<o:p></o:p></span></font></pre><pre><font size=3D2 color=3Dnavy face=3DArial><span style=3D'font-size:10.0pt;font-fam= ily:Arial; color:navy'>   from the home agent and thus enable robust Route O= ptimization even in<o:p></o:p></span></font></pre><pre><font size=3D2 color=3Dnavy face=3DArial><span style=3D'font-size:10.0pt;font-fam= ily:Arial; color:navy'>   the absence of the home agent.<o:p></o:p></span></= font></pre> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style= =3D'font-size: 10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style= =3D'font-size: 10.0pt;font-family:Arial;color:navy'>Regards,<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style= =3D'font-size: 10.0pt;font-family:Arial;color:navy'>- Georg<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3D"Courier New"><span lang=3DEN style=3D'font-size:10.0pt;font-family:"Courier New"'><o:p> </o:p></spa= n></font></p> <p class=3DMsoNormal><font size=3D2 face=3D"Courier New"><span lang=3DEN style=3D'font-size:10.0pt;font-family:"Courier New"'>   &nbs= p;            &= nbsp;    <o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3D"Times New Roman"><span lang=3DE= N style=3D'font-size:10.0pt'><o:p> </o:p></span></font></p> </div> <div> <div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font siz= e=3D3 face=3D"Times New Roman"><span style=3D'font-size:12.0pt'> <hr size=3D2 width=3D"100%" align=3Dcenter tabindex=3D-1> </span></font></div> <p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span style=3D'font-si= ze:10.0pt; font-family:Tahoma;font-weight:bold'>From:</span></font></b><font face=3DTa= homa><span style=3D'font-family:Tahoma'> Laganier, Julien [mailto:julienl@qualcomm.com= ] <br> <b><span style=3D'font-weight:bold'>Sent:</span></b> Saturday, January 22, = 2011 1:47 AM<br> <b><span style=3D'font-weight:bold'>To:</span></b> <st1:PersonName w:st=3D"= on">Hampel, K Georg</st1:PersonName> (K Georg); <st1:PersonName w:st=3D"on">mext@ietf.= org</st1:PersonName><br> <b><span style=3D'font-weight:bold'>Cc:</span></b> <st1:PersonName w:st=3D"= on">Klein, Thierry E</st1:PersonName> (Thierry)<br> <b><span style=3D'font-weight:bold'>Subject:</span></b> RE: Support of rout= e optimization in *absence* of HA</span></font><font size=3D3><span style=3D'font-size:12.0pt'><o:p></o:p></span></font></p> </div> <p class=3DMsoNormal><font size=3D2 face=3D"Times New Roman"><span style=3D= 'font-size: 10.0pt'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" face=3DCalibri><span style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'>Georg,<o:p></o= :p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" face=3DCalibri><span style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'><o:p> </o= :p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" face=3DCalibri><span style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'>Regarding #1 I haven’t decided yet I would like the group to discuss more. The authorization of the MN to use a given HA could be asserted in a couple of different ways, including but not limited to, a) the HA only allows creatio= n of initial binding for on-(home)-link MN, b) the HA only allows creation of initial bindings for on-site MNs, i.e., CoA in a provider prefix block, and= c) the HA has access to a list of CGA public keys that are authorized to creat= e bindings.<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" face=3DCalibri><span style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'><o:p> </o= :p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" face=3DCalibri><span style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'>Regarding #2, = if I am not mistaken, at least the 3GPP Evolved Packet System mandates stateless address autoconfiguration for global addresses. Only the link-local address= is generated from the IID sent by the GW.<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" face=3DCalibri><span style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'><o:p> </o= :p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" face=3DCalibri><span style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'>Best,<o:p></o:= p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" face=3DCalibri><span style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'><o:p> </o= :p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" face=3DCalibri><span style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'>--julien<o:p><= /o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" face=3DCalibri><span style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'> <o:p></o= :p></span></font></p> <div style=3D'border:none;border-left:solid blue 1.5pt;padding:0pt 0pt 0pt = 4.0pt'> <div> <div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0pt = 0pt 0pt'> <p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span style=3D'font-si= ze:10.0pt; font-family:Tahoma;font-weight:bold'>From:</span></font></b><font face=3DTa= homa><span style=3D'font-family:Tahoma'> <st1:PersonName w:st=3D"on">Hampel, K Georg</= st1:PersonName> (K Georg) [mailto:georg.hampel@alcatel-lucent.com] <br> <b><span style=3D'font-weight:bold'>Sent:</span></b> Friday, January 21, 20= 11 11:22 AM<br> <b><span style=3D'font-weight:bold'>To:</span></b> Laganier, Julien; <st1:P= ersonName w:st=3D"on">Hampel, K Georg</st1:PersonName> (K Georg); <st1:PersonName w:s= t=3D"on">mext@ietf.org</st1:PersonName><br> <b><span style=3D'font-weight:bold'>Cc:</span></b> <st1:PersonName w:st=3D"= on">Klein, Thierry E</st1:PersonName> (Thierry)<br> <b><span style=3D'font-weight:bold'>Subject:</span></b> RE: Support of rout= e optimization in *absence* of HA<o:p></o:p></span></font></p> </div> </div> <p class=3DMsoNormal><font size=3D2 face=3D"Times New Roman"><span style=3D= 'font-size: 10.0pt'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style= =3D'font-size: 10.0pt;font-family:Arial;color:navy'>Julien,<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style= =3D'font-size: 10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style= =3D'font-size: 10.0pt;font-family:Arial;color:navy'>Thanks for the info. I like your propo= sal. CGA provides cryptographic security without need for trust-relationships, P= KI, pre-shared keys, etc.<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style= =3D'font-size: 10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style= =3D'font-size: 10.0pt;font-family:Arial;color:navy'>1) When IPsec is replaced by <st1:plac= e w:st=3D"on"><st1:City w:st=3D"on">CGA</st1:City>, <st1:State w:st=3D"on">MN= </st1:State></st1:place> only proves the authenticity of its HoA to the HA. It does not authenticate itself in absolute terms, i.e. via means of strong authentication as requir= ed by IPsec or TLS. How would the HA know that this MN is authorized to use th= e HA’s services?  <o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style= =3D'font-size: 10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style= =3D'font-size: 10.0pt;font-family:Arial;color:navy'>2) Do we have any idea to what extend stateless addressing is “supported”? Does (or will) 3GPP allow stateless addressing?<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style= =3D'font-size: 10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style= =3D'font-size: 10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style= =3D'font-size: 10.0pt;font-family:Arial;color:navy'>-Georg<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style= =3D'font-size: 10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style= =3D'font-size: 10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p> <div> <div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font siz= e=3D3 face=3D"Times New Roman"><span style=3D'font-size:12.0pt'> <hr size=3D2 width=3D"100%" align=3Dcenter> </span></font></div> <p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span style=3D'font-si= ze:10.0pt; font-family:Tahoma;font-weight:bold'>From:</span></font></b><font face=3DTa= homa><span style=3D'font-family:Tahoma'> Laganier, Julien [mailto:julienl@qualcomm.com= ] <br> <b><span style=3D'font-weight:bold'>Sent:</span></b> Friday, January 21, 20= 11 1:06 PM<br> <b><span style=3D'font-weight:bold'>To:</span></b> <st1:PersonName w:st=3D"= on">Hampel, K Georg</st1:PersonName> (K Georg); <st1:PersonName w:st=3D"on">mext@ietf.= org</st1:PersonName><br> <b><span style=3D'font-weight:bold'>Cc:</span></b> <st1:PersonName w:st=3D"= on">Klein, Thierry E</st1:PersonName> (Thierry)<br> <b><span style=3D'font-weight:bold'>Subject:</span></b> RE: Support of rout= e optimization in *absence* of HA</span></font><font size=3D3><span style=3D'font-size:12.0pt'><o:p></o:p></span></font></p> </div> <p class=3DMsoNormal><font size=3D2 face=3D"Times New Roman"><span style=3D= 'font-size: 10.0pt'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" face=3DCalibri><span style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'>Georg,<o:p></o= :p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" face=3DCalibri><span style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'><o:p> </o= :p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" face=3DCalibri><span style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'>Thanks for clarifying, this is what I thought. FWIW, I’ve tried to extend the RF= C 4866 to secure bindings between the MN and the HA in </span></font><a href=3D"http://tools.ietf.org/html/draft-laganier-mext-cga-01">http://tools= .ietf.org/html/draft-laganier-mext-cga-01</a><o:p></o:p></p> <p class=3DMsoNormal><font size=3D2 face=3D"Times New Roman"><span style=3D= 'font-size: 10.0pt'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" face=3DCalibri><span style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'>--julien<o:p><= /o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" face=3DCalibri><span style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'><o:p> </o= :p></span></font></p> <div style=3D'border:none;border-left:solid blue 1.5pt;padding:0pt 0pt 0pt = 4.0pt'> <div> <div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0pt = 0pt 0pt'> <p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span style=3D'font-si= ze:10.0pt; font-family:Tahoma;font-weight:bold'>From:</span></font></b><font face=3DTa= homa><span style=3D'font-family:Tahoma'> <st1:PersonName w:st=3D"on">Hampel, K Georg</= st1:PersonName> (K Georg) [mailto:georg.hampel@alcatel-lucent.com] <br> <b><span style=3D'font-weight:bold'>Sent:</span></b> Thursday, January 20, = 2011 5:25 PM<br> <b><span style=3D'font-weight:bold'>To:</span></b> Laganier, Julien; <st1:P= ersonName w:st=3D"on">mext@ietf.org</st1:PersonName><br> <b><span style=3D'font-weight:bold'>Cc:</span></b> <st1:PersonName w:st=3D"= on">Klein, Thierry E</st1:PersonName> (Thierry)<br> <b><span style=3D'font-weight:bold'>Subject:</span></b> RE: Support of rout= e optimization in *absence* of HA<o:p></o:p></span></font></p> </div> </div> <p class=3DMsoNormal><font size=3D2 face=3D"Times New Roman"><span style=3D= 'font-size: 10.0pt'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span lang=3D= EN style=3D'font-size:10.0pt;font-family:Arial;color:navy'>Julien,<o:p></o:p><= /span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span lang=3D= EN style=3D'font-size:10.0pt;font-family:Arial;color:navy'><o:p> </o:p></= span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span lang=3D= EN style=3D'font-size:10.0pt;font-family:Arial;color:navy'>The intentions of Homeless MIPv6 are similar to those of our proposal. <o:p></o:p></span></fo= nt></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span lang=3D= EN style=3D'font-size:10.0pt;font-family:Arial;color:navy'><o:p> </o:p></= span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span lang=3D= EN style=3D'font-size:10.0pt;font-family:Arial;color:navy'>In contrast to Home= less MIPv6, our proposal requires only minimal upgrades to the present standard = and implementation. (Homeless MIPv6 requires changes to the TCP/UDP and require= s AH, for instance).<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span lang=3D= EN style=3D'font-size:10.0pt;font-family:Arial;color:navy'><o:p> </o:p></= span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span lang=3D= EN style=3D'font-size:10.0pt;font-family:Arial;color:navy'>Here’s the co= re idea of HA-free R/O: <o:p></o:p></span></font></p> <p class=3DMsoNormal style=3D'margin-left:36.0pt;text-indent:-18.0pt;mso-li= st:l3 level1 lfo2'><![if !supportLists]><font size=3D2 color=3Dnavy face=3DArial><span lang=3DEN style=3D'font-size:10.0p= t;font-family: Arial;color:navy'><span style=3D'mso-list:Ignore'>1)<font size=3D1 face=3D"Times New Roman"><span style=3D'font:7.0pt "Times New Roman"'> = ;      </span></font></span></span></font><![endif]><font color=3Dnavy face=3DAria= l><span lang=3DEN style=3D'font-family:Arial;color:navy'>When starting a session, t= he MN self-declares its current IP address as the “HoA” for this sess= ion. This automatically means that it resides in its “home network” = and can conduct the home test directly with CN, i.e. no home registration requi= red.<o:p></o:p></span></font></p> <p class=3DMsoNormal style=3D'margin-left:36.0pt;text-indent:-18.0pt;mso-li= st:l3 level1 lfo2'><![if !supportLists]><font size=3D2 color=3Dnavy face=3DArial><span lang=3DEN style=3D'font-size:10.0p= t;font-family: Arial;color:navy'><span style=3D'mso-list:Ignore'>2)<font size=3D1 face=3D"Times New Roman"><span style=3D'font:7.0pt "Times New Roman"'> = ;      </span></font></span></span></font><![endif]><font color=3Dnavy face=3DAria= l><span lang=3DEN style=3D'font-family:Arial;color:navy'>All further BU/BA signalin= g is done directly with CN according to RFC 4866.<o:p></o:p></span></font></p> <p class=3DMsoNormal style=3D'margin-left:36.0pt;text-indent:-18.0pt;mso-li= st:l3 level1 lfo2'><![if !supportLists]><font size=3D2 color=3Dnavy face=3DArial><span lang=3DEN style=3D'font-size:10.0p= t;font-family: Arial;color:navy'><span style=3D'mso-list:Ignore'>3)<font size=3D1 face=3D"Times New Roman"><span style=3D'font:7.0pt "Times New Roman"'> = ;      </span></font></span></span></font><![endif]><font color=3Dnavy face=3DAria= l><span lang=3DEN style=3D'font-family:Arial;color:navy'>All further signaling with= HA is simply omitted.<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span lang=3D= EN style=3D'font-size:10.0pt;font-family:Arial;color:navy'><o:p> </o:p></= span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span lang=3D= EN style=3D'font-size:10.0pt;font-family:Arial;color:navy'>Our proposal builds= on “enhanced route optimization” (RFC 4866), which provides a nice security solution for R/O and creates the ground for HA-free operation.<o:p= ></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span lang=3D= EN style=3D'font-size:10.0pt;font-family:Arial;color:navy'>Little changes are required: e.g. MN must be able to deregister its HoA at CN, etc.<o:p></o:p>= </span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span lang=3D= EN style=3D'font-size:10.0pt;font-family:Arial;color:navy'><o:p> </o:p></= span></font></p> <div> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span lang=3D= EN style=3D'font-size:10.0pt;font-family:Arial;color:navy'>Regards,<o:p></o:p>= </span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span lang=3D= EN style=3D'font-size:10.0pt;font-family:Arial;color:navy'><o:p> </o:p></= span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span lang=3D= EN style=3D'font-size:10.0pt;font-family:Arial;color:navy'>Georg<o:p></o:p></s= pan></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3D"Times New Roman"><= span style=3D'font-size:10.0pt;color:navy'><o:p> </o:p></span></font></p> </div> <div> <div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font siz= e=3D3 face=3D"Times New Roman"><span style=3D'font-size:12.0pt'> <hr size=3D2 width=3D"100%" align=3Dcenter> </span></font></div> <p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span style=3D'font-si= ze:10.0pt; font-family:Tahoma;font-weight:bold'>From:</span></font></b><font face=3DTa= homa><span style=3D'font-family:Tahoma'> Laganier, Julien [mailto:julienl@qualcomm.com= ] <br> <b><span style=3D'font-weight:bold'>Sent:</span></b> Thursday, January 20, = 2011 4:27 PM<br> <b><span style=3D'font-weight:bold'>To:</span></b> <st1:PersonName w:st=3D"= on">Hampel, K Georg</st1:PersonName> (K Georg); <st1:PersonName w:st=3D"on">mext@ietf.= org</st1:PersonName><br> <b><span style=3D'font-weight:bold'>Cc:</span></b> <st1:PersonName w:st=3D"= on">Klein, Thierry E</st1:PersonName> (Thierry)<br> <b><span style=3D'font-weight:bold'>Subject:</span></b> RE: Support of rout= e optimization in *absence* of HA</span></font><font size=3D3><span style=3D'font-size:12.0pt'><o:p></o:p></span></font></p> </div> <p class=3DMsoNormal><font size=3D2 face=3D"Times New Roman"><span style=3D= 'font-size: 10.0pt'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" face=3DCalibri><span style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'>Georg,<o:p></o= :p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" face=3DCalibri><span style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'><o:p> </o= :p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" face=3DCalibri><span style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'>Is it correct = that functionally your proposal is similar to Homeless Mobile IPv6:<o:p></o:p></= span></font></p> <p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" face=3DCalibri><span style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'><o:p> </o= :p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3D"Times New Roman"><span style=3D= 'font-size: 10.0pt'><a href=3D"http://tools.ietf.org/html/draft-nikander-mobileip-homelessv6-01">h= ttp://tools.ietf.org/html/draft-nikander-mobileip-homelessv6-01</a><o:p></o= :p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3D"Times New Roman"><span style=3D= 'font-size: 10.0pt'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" face=3DCalibri><span style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'>Best,<o:p></o:= p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" face=3DCalibri><span style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'><o:p> </o= :p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" face=3DCalibri><span style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'>--julien<o:p><= /o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" face=3DCalibri><span style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'><o:p> </o= :p></span></font></p> <div style=3D'border:none;border-left:solid blue 1.5pt;padding:0pt 0pt 0pt = 4.0pt'> <div> <div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0pt = 0pt 0pt'> <p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span style=3D'font-si= ze:10.0pt; font-family:Tahoma;font-weight:bold'>From:</span></font></b><font face=3DTa= homa><span style=3D'font-family:Tahoma'> mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] <b><span style=3D'font-weight:bold'>On Behal= f Of </span></b><st1:PersonName w:st=3D"on">Hampel, K Georg</st1:PersonName> (K Georg)<br> <b><span style=3D'font-weight:bold'>Sent:</span></b> Thursday, January 20, = 2011 12:07 PM<br> <b><span style=3D'font-weight:bold'>To:</span></b> <st1:PersonName w:st=3D"= on">mext@ietf.org</st1:PersonName><br> <b><span style=3D'font-weight:bold'>Cc:</span></b> <st1:PersonName w:st=3D"= on">Hampel, K Georg</st1:PersonName> (K Georg); <st1:PersonName w:st=3D"on">Klein, Thi= erry E</st1:PersonName> (Thierry)<br> <b><span style=3D'font-weight:bold'>Subject:</span></b> [MEXT] Support of r= oute optimization in *absence* of HA<o:p></o:p></span></font></p> </div> </div> <p class=3DMsoNormal><font size=3D2 face=3D"Times New Roman"><span style=3D= 'font-size: 10.0pt'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1= 0.5pt; font-family:Arial'>All,<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1= 0.5pt; font-family:Arial'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1= 0.5pt; font-family:Arial'>We would like to add a proposal to MEXT that permits the mobile to engage into route-optimization in *absence* of a home agent. <o:p= ></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1= 0.5pt; font-family:Arial'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1= 0.5pt; font-family:Arial'>Such a feature adds robustness to route optimization in = case the HA is temporarily unavailable. Under some circumstances, route optimiza= tion *without* HA may be beneficial for performance reasons. Our proposal requir= es “enhanced route optimization for Mobile IPv6” (RFC 4866) as pre-requisite.<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1= 0.5pt; font-family:Arial'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1= 0.5pt; font-family:Arial'>We would like to obtain some feedback from the MEXT community via this mailing list before we submit the proposal as a draft to= the workgroup. For this purpose, we have enclosed a high-level outline below. Thanks.<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1= 0.5pt; font-family:Arial'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1= 0.5pt; font-family:Arial'>Regards,<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1= 0.0pt; font-family:Arial'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><st1:PersonName w:st=3D"on"><font size=3D2 face=3DAria= l><span style=3D'font-size:10.0pt;font-family:Arial'>Georg Hampel</span></font></s= t1:PersonName><font face=3DArial><span style=3D'font-family:Arial'><o:p></o:p></span></font></p= > <p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1= 0.0pt; font-family:Arial'>Networking & Networks Domain<o:p></o:p></span></font= ></p> <p class=3DMsoNormal><st1:City w:st=3D"on"><st1:place w:st=3D"on"><font siz= e=3D2 face=3DArial><span style=3D'font-size:10.0pt;font-family:Arial'>Bell</spa= n></font></st1:place></st1:City><font face=3DArial><span style=3D'font-family:Arial'> Laboratories<o:p></o:p></sp= an></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1= 0.0pt; font-family:Arial'>Alcatel-Lucent<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1= 0.0pt; font-family:Arial'>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1= 0.0pt; font-family:Arial'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1= 0.5pt; font-family:Arial'>Proposal: Support of Route-Optimization in Absence of Ho= me Agent<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1= 0.5pt; font-family:Arial'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1= 0.5pt; font-family:Arial'>ABSTRACT:<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1= 0.5pt; font-family:Arial'>The proposal allows the mobile to engage into route optimization (R/O) in *absence* of a HA. This feature increases robustness = when the HA becomes temporarily unavailable. Under some circumstances, R/O *with= out* HA may be beneficial for performance reasons. This proposal requires “enhanced route optimization for Mobile IPv6” (RFC 4866) as pre-requisite. <o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1= 0.5pt; font-family:Arial'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1= 0.5pt; font-family:Arial'>MOTIVATION:<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1= 0.5pt; font-family:Arial'>In route optimization (R/O), traffic packets are directl= y exchanged between hosts without passing the HA. The mobile, however, still = has to interact with the HA. The HA provides (1) location service, (2) a fallba= ck path in case the direct path breaks, (3) a fallback in case the corresponde= nt does not support the protocol and (4) security support for R/O-related signaling (i.e. home test). These functions come at the following cost:<o:p= ></o:p></span></font></p> <p class=3DMsoNormal style=3D'margin-left:14.0pt;text-indent:-14.0pt;mso-li= st:l4 level1 lfo4'><![if !supportLists]><font size=3D1 face=3DSymbol><span style=3D'font-size:9.0pt;font-family:Symbol'><= span style=3D'mso-list:Ignore'>·<font size=3D1 face=3D"Times New Roman"><= span style=3D'font:7.0pt "Times New Roman"'>      = </span></font></span></span></font><![endif]><font size=3D2 face=3DArial><span style=3D'font-size:10.5pt;font-family:Arial'>Ha= ndovers may fail when the link to the HA or the HA itself are down or congested. Mobility is not supported, when the mobile does not have a HA.<o:p></o:p></= span></font></p> <p class=3DMsoNormal style=3D'margin-left:14.0pt;text-indent:-14.0pt;mso-li= st:l4 level1 lfo4'><![if !supportLists]><font size=3D1 face=3DSymbol><span style=3D'font-size:9.0pt;font-family:Symbol'><= span style=3D'mso-list:Ignore'>·<font size=3D1 face=3D"Times New Roman"><= span style=3D'font:7.0pt "Times New Roman"'>      = </span></font></span></span></font><![endif]><font size=3D2 face=3DArial><span style=3D'font-size:10.5pt;font-family:Arial'>Wh= en the mobile starts a session outside of its home network, it must use a HoA pertaining to its home network even if it engages into R/O. This requiremen= t adds air-interface overhead due to mobility headers and processing overhead= on the mobile. This upfront cost incurs even if the mobile does not move durin= g the session.<o:p></o:p></span></font></p> <p class=3DMsoNormal style=3D'margin-left:14.0pt;text-indent:-14.0pt;mso-li= st:l4 level1 lfo4'><![if !supportLists]><font size=3D1 face=3DSymbol><span style=3D'font-size:9.0pt;font-family:Symbol'><= span style=3D'mso-list:Ignore'>·<font size=3D1 face=3D"Times New Roman"><= span style=3D'font:7.0pt "Times New Roman"'>      = </span></font></span></span></font><![endif]><font size=3D2 face=3DArial><span style=3D'font-size:10.5pt;font-family:Arial'>Si= gnaling handshakes have to be conducted between mobile and HA at every mobility eve= nt.<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1= 0.5pt; font-family:Arial'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1= 0.5pt; font-family:Arial'>Currently, the Mobile IPv6 standard family forces the mo= bile to bear these disadvantages in R/O even if the HA functions are not needed. This specifically applies to scenarios where: <o:p></o:p></span></font></p> <p class=3DMsoNormal style=3D'margin-left:14.0pt;text-indent:-14.0pt;mso-li= st:l0 level1 lfo6'><![if !supportLists]><font size=3D1 face=3DSymbol><span style=3D'font-size:9.0pt;font-family:Symbol'><= span style=3D'mso-list:Ignore'>·<font size=3D1 face=3D"Times New Roman"><= span style=3D'font:7.0pt "Times New Roman"'>      = </span></font></span></span></font><![endif]><font size=3D2 face=3DArial><span style=3D'font-size:10.5pt;font-family:Arial'>Tr= affic is based on mobile-initiated requests to public servers (majority of present mobile internet traffic). The HA’s location service is not needed for such traffic. Location service may also be provided by other means such as Dynamic DNS or on application layer (e.g. SIP registrar).<o:p></o:p></span>= </font></p> <p class=3DMsoNormal style=3D'margin-left:14.0pt;text-indent:-14.0pt;mso-li= st:l0 level1 lfo6'><![if !supportLists]><font size=3D1 face=3DSymbol><span style=3D'font-size:9.0pt;font-family:Symbol'><= span style=3D'mso-list:Ignore'>·<font size=3D1 face=3D"Times New Roman"><= span style=3D'font:7.0pt "Times New Roman"'>      = </span></font></span></span></font><![endif]><font size=3D2 face=3DArial><span style=3D'font-size:10.5pt;font-family:Arial'>Th= e fallback path through the HA has little value when it shares the weakest link with t= he direct path. Since the weakest link is typically the wireless link, this situation applies to all scenarios where only one air interface is availabl= e (this is the typical case rather than the exception).<o:p></o:p></span></fo= nt></p> <p class=3DMsoNormal style=3D'margin-left:14.0pt;text-indent:-14.0pt;mso-li= st:l0 level1 lfo6'><![if !supportLists]><font size=3D1 face=3DSymbol><span style=3D'font-size:9.0pt;font-family:Symbol'><= span style=3D'mso-list:Ignore'>·<font size=3D1 face=3D"Times New Roman"><= span style=3D'font:7.0pt "Times New Roman"'>      = </span></font></span></span></font><![endif]><font size=3D2 face=3DArial><span style=3D'font-size:10.5pt;font-family:Arial'>Th= e mobile may know about the correspondent’s Mobile-IPv6 support from prior sessions or through means external to the standard. <o:p></o:p></span></fon= t></p> <p class=3DMsoNormal style=3D'margin-left:14.0pt;text-indent:-14.0pt;mso-li= st:l0 level1 lfo6'><![if !supportLists]><font size=3D1 face=3DSymbol><span style=3D'font-size:9.0pt;font-family:Symbol'><= span style=3D'mso-list:Ignore'>·<font size=3D1 face=3D"Times New Roman"><= span style=3D'font:7.0pt "Times New Roman"'>      = </span></font></span></span></font><![endif]><font size=3D2 face=3DArial><span style=3D'font-size:10.5pt;font-family:Arial'>Th= e mobile applies the CGA-based procedure of RFC 4866, which makes the HA’s security support for R/O unnecessary. This applies to all cases where state= less addressing is permitted. <o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1= 0.5pt; font-family:Arial'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1= 0.5pt; font-family:Arial'>To increase the flexibility and robustness of route-optimized Mobile IPv6, we propose to make the HA an *optional* rather than a *mandatory* feature, i.e. to permit operation without HA. This propo= sal requires some additional extensions to the present standard.<o:p></o:p></sp= an></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1= 0.5pt; font-family:Arial'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1= 0.5pt; font-family:Arial'>HIGH-LEVEL OUTLINE<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1= 0.5pt; font-family:Arial'>The extensions build on Enhanced Route Optimization for Mobile IPv6 (RFC 4866) to guarantee sufficient signaling security. With the absence of a HA, mobility support in R/O can be provided in the following manner:<o:p></o:p></span></font></p> <p class=3DMsoNormal style=3D'margin-left:14.0pt;text-indent:-14.0pt;mso-li= st:l1 level1 lfo8'><![if !supportLists]><font size=3D1 face=3DSymbol><span style=3D'font-size:9.0pt;font-family:Symbol'><= span style=3D'mso-list:Ignore'>·<font size=3D1 face=3D"Times New Roman"><= span style=3D'font:7.0pt "Times New Roman"'>      = </span></font></span></span></font><![endif]><font size=3D2 face=3DArial><span style=3D'font-size:10.5pt;font-family:Arial'>Th= e mobile starts the traffic session from any of its currently supported IP addresses= . The selected IP address automatically takes the function of the HoA for thi= s session. This has the advantage that conventional transport is used as long= as the mobile does not move, i.e. mobility headers and CoA-vs-HoA mapping is n= ot needed. The HoA must have been generated via CGA in compliance with RFC 486= 6. <o:p></o:p></span></font></p> <p class=3DMsoNormal style=3D'margin-left:14.0pt;text-indent:-14.0pt;mso-li= st:l1 level1 lfo8'><![if !supportLists]><font size=3D1 face=3DSymbol><span style=3D'font-size:9.0pt;font-family:Symbol'><= span style=3D'mso-list:Ignore'>·<font size=3D1 face=3D"Times New Roman"><= span style=3D'font:7.0pt "Times New Roman"'>      = </span></font></span></span></font><![endif]><font size=3D2 face=3DArial><span style=3D'font-size:10.5pt;font-family:Arial'>Th= e mobile must conduct a “home-test” from this HoA in compliance with RFC 4866. It may conduct the home-test prior to session establishment, e.g. to = find out if the correspondent supports the standard. <o:p></o:p></span></font></= p> <p class=3DMsoNormal style=3D'margin-left:14.0pt;text-indent:-14.0pt;mso-li= st:l1 level1 lfo8'><![if !supportLists]><font size=3D1 face=3DSymbol><span style=3D'font-size:9.0pt;font-family:Symbol'><= span style=3D'mso-list:Ignore'>·<font size=3D1 face=3D"Times New Roman"><= span style=3D'font:7.0pt "Times New Roman"'>      = </span></font></span></span></font><![endif]><font size=3D2 face=3DArial><span style=3D'font-size:10.5pt;font-family:Arial'>Al= l binding update handshakes are conducted on the direct path according to RFC 4866.<o= :p></o:p></span></font></p> <p class=3DMsoNormal style=3D'margin-left:14.0pt;text-indent:-14.0pt;mso-li= st:l1 level1 lfo8'><![if !supportLists]><font size=3D1 face=3DSymbol><span style=3D'font-size:9.0pt;font-family:Symbol'><= span style=3D'mso-list:Ignore'>·<font size=3D1 face=3D"Times New Roman"><= span style=3D'font:7.0pt "Times New Roman"'>      = </span></font></span></span></font><![endif]><font size=3D2 face=3DArial><span style=3D'font-size:10.5pt;font-family:Arial'>Si= nce sessions are always started from a currently supported IP address, temporal= ly overlapping sessions may use different HoAs. A multi-homed mobile may also decide to start sessions from different simultaneously supported IP address= es. There is no principle problem here.<o:p></o:p></span></font></p> <p class=3DMsoNormal style=3D'margin-left:14.0pt;text-indent:-14.0pt;mso-li= st:l1 level1 lfo8'><![if !supportLists]><font size=3D1 face=3DSymbol><span style=3D'font-size:9.0pt;font-family:Symbol'><= span style=3D'mso-list:Ignore'>·<font size=3D1 face=3D"Times New Roman"><= span style=3D'font:7.0pt "Times New Roman"'>      = </span></font></span></span></font><![endif]><font size=3D2 face=3DArial><span style=3D'font-size:10.5pt;font-family:Arial'>Op= posed to RFC 4866, the mobile need not perform the CoA registration with the HA.<o:p= ></o:p></span></font></p> <p class=3DMsoNormal style=3D'margin-left:14.0pt;text-indent:-14.0pt;mso-li= st:l1 level1 lfo8'><![if !supportLists]><font size=3D1 face=3DSymbol><span style=3D'font-size:9.0pt;font-family:Symbol'><= span style=3D'mso-list:Ignore'>·<font size=3D1 face=3D"Times New Roman"><= span style=3D'font:7.0pt "Times New Roman"'>      = </span></font></span></span></font><![endif]><font size=3D2 face=3DArial><span style=3D'font-size:10.5pt;font-family:Arial'>Th= e mobile must be able to deregister the HoA at the correspondent in case the HoA is = not supported anymore. This ensures that the correspondent does not send packet= s to the HoA. After deregistration of the HoA, the HoA is still used by higher protocol layers of ongoing sessions. It must still be included in the mobil= ity headers for these sessions.<o:p></o:p></span></font></p> <p class=3DMsoNormal style=3D'margin-left:14.0pt;text-indent:-14.0pt;mso-li= st:l1 level1 lfo8'><![if !supportLists]><font size=3D1 face=3DSymbol><span style=3D'font-size:9.0pt;font-family:Symbol'><= span style=3D'mso-list:Ignore'>·<font size=3D1 face=3D"Times New Roman"><= span style=3D'font:7.0pt "Times New Roman"'>      = </span></font></span></span></font><![endif]><font size=3D2 face=3DArial><span style=3D'font-size:10.5pt;font-family:Arial'>Wh= en the mobile has HA support and the HA becomes temporarily unavailable, the mobil= e simply continues R/O without HA as outlined in the prior points.<o:p></o:p>= </span></font></p> <p class=3DMsoNormal style=3D'margin-left:14.0pt;text-indent:-14.0pt;mso-li= st:l1 level1 lfo8'><![if !supportLists]><font size=3D1 face=3DSymbol><span style=3D'font-size:9.0pt;font-family:Symbol'><= span style=3D'mso-list:Ignore'>·<font size=3D1 face=3D"Times New Roman"><= span style=3D'font:7.0pt "Times New Roman"'>      = </span></font></span></span></font><![endif]><font size=3D2 face=3DArial><span style=3D'font-size:10.5pt;font-family:Arial'>Th= e mobile can publish its IP address in any location service. This allows other hosts= to initiate sessions with the mobile. These sessions enjoy route-optimized mobility support only if the published IP address was generated via CGA in compliance with RFC 4866.<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1= 0.5pt; font-family:Arial'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1= 0.5pt; font-family:Arial'>OPEN ISSUES<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1= 0.5pt; font-family:Arial'>These extensions have to be made compliant with RFC 5648 (multiple CoA registration), RFC 3963 (NEMO) and others. More discussions a= re necessary.<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1= 0.5pt; font-family:Arial'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN style=3D'f= ont-size:10.5pt; font-family:Arial'><o:p> </o:p></span></font></p> </div> </div> </div> </div> </body> </html> --_000_154773479ED2314980CB638A48FC4434833B9F67USNAVSXCHMBSA2n_-- From wwwrun@core3.amsl.com Tue Jan 25 09:39:39 2011 Return-Path: <wwwrun@core3.amsl.com> X-Original-To: mext@ietf.org Delivered-To: mext@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 7E8B43A683E; Tue, 25 Jan 2011 09:39:39 -0800 (PST) From: IESG Secretary <iesg-secretary@ietf.org> To: IETF Announcement list <ietf-announce@ietf.org> Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20110125173939.7E8B43A683E@core3.amsl.com> Date: Tue, 25 Jan 2011 09:39:39 -0800 (PST) Cc: julienl@qualcomm.com, mext@ietf.org Subject: [MEXT] WG Action: RECHARTER: Mobility EXTensions for IPv6 (mext) X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG <mext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/mext> List-Post: <mailto:mext@ietf.org> List-Help: <mailto:mext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 25 Jan 2011 17:39:39 -0000 The Mobility EXTensions for IPv6 (mext) working group in the Internet Area of the IETF has been rechartered. For additional information, please contact the Area Directors or the working group Chairs. Mobility EXTensions for IPv6 (mext) ----------------------------------- Current Status: Active Last updated: 2011-01-11 Chairs: Marcelo Bagnulo <marcelo@it.uc3m.es> Julien Laganier <julienl@qualcomm.com> Internet Area Directors: Ralph Droms <rdroms.ietf@gmail.com> Jari Arkko <jari.arkko@piuha.net> Internet Area Advisor: Jari Arkko <jari.arkko@piuha.net> Mailing Lists: General Discussion: mext@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/mext Archive: http://www.ietf.org/mail-archive/web/mext Description of Working Group: Mobile IPv6 specifies routing support which permits an IPv6 host to continue using its home address as it moves around the Internet, enabling continuity of sessions. Mobile IPv6 supports transparency above the IP layer, including maintenance of active transport level sessions. In addition, network mobility (NEMO) mechanisms built on top of Mobile IPv6 allow managing the mobility of an entire network, as it changes its point of attachment to the Internet. The base specifications consist of: o RFC 3775 (Mobile IPv6) o RFC 3963 (NEMO) o RFC 4877 (Mobile IPv6 Operation with IKEv2) o RFC 5555 (Dual Stack Mobile IPv6) o RFC 5648 (Multiple Care-of Addresses Registration) o RFC 5846 (Binding Revocation) o RFC-to-be (Flow Binding Policy Transport and Flow Binding Policy Format) The MEXT Working Group continues the work of the former MIP6, NEMO, and MONAMI6 Working Groups. The primary goal of MEXT will be to enhance base IPv6 mobility by continuing work on developments that are required for wide-scale deployments and specific deployment scenarios. Additionally, the working group will ensure that any issues identified by implementation and interoperability experience are addressed, and that the base specifications are maintained. The group will also produce informational documentation, such as design rationale documents or description of specific issues within the protocol. The MEXT WG will also explore experimental alternative security mechanisms. The security mechanism specified in the existing standard track RFCs (RFC3775bis, RFC4877) remains the mandatory to implement mechanism that guarantees interoperability between different implementations. The MEXT WG is chartered to deliver one or more experimental alternative mechanisms. All the alternative solutions will be published as experimental RFCs. The working group will also work on operational considerations on setting up Mobile IPv6 networks so that traffic is distributed in an optimal way, for instance by using existing protocol mechanisms to select the closest home agents for new clients. In addition, the working group will bring to completion earlier work on prefix delegation for NEMO, RADIUS support for Mobile IPv6, Mobile IPv6 operation with firewalls, and home agent reliability specifications. Work items related to base specification maintenance include: Create and maintain issue lists that are generated on the basis of implementation and interoperability experience. Address specific issues with specific updates or revisions of the base specification. Currently known specific issues include support for overlapping (private) IPv4 home addresses, negotiation of the protection required for payload traffic, and discovery of the home agent address in IPv4-only networks. Goals and Milestones: Jun 2011 - Submit I-D 'Mobile IPv6 Operation with Firewalls' to IESG for publication as Informational. Jun 2011 - Submit I-D 'Home agent reliability' to IESG for publication as a Proposed Standard. Aug 2011 - Submit I-Ds on alternative security mechanisms to the IESG for publication as Experimental. Sep 2011 - Submit I-D 'Overlapping IPv4 address support' to IESG for publication as Proposed Standard. Sep 2011 - Submit I-D 'Home agent discovery in IPv4-only networks via DHCP' to IESG for publication as Proposed Standard. Oct 2011 - Submit I-D 'Operational considerations for distributed use of Mobile IPv6' for publication as Informational Dec 2011 - Submit I-D 'Negotiation of the protection for payload traffic' to IESG for publication as Proposed Standard. Dec 2011 - Submit the I-D 'RADIUS Mobile IPv6 Support' to IESG for publication as a proposed standard. From alexandru.petrescu@gmail.com Tue Jan 25 09:52:06 2011 Return-Path: <alexandru.petrescu@gmail.com> X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9126B3A687F for <mext@core3.amsl.com>; Tue, 25 Jan 2011 09:52:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.163 X-Spam-Level: X-Spam-Status: No, score=-2.163 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Muyvjr+X8byC for <mext@core3.amsl.com>; Tue, 25 Jan 2011 09:52:04 -0800 (PST) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.166.172.106]) by core3.amsl.com (Postfix) with ESMTP id 2BEED3A6875 for <mext@ietf.org>; Tue, 25 Jan 2011 09:52:04 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id p0PHt0jj028801 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 25 Jan 2011 18:55:00 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id p0PHt0nN021476; Tue, 25 Jan 2011 18:55:00 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [132.166.133.173] (is010173.intra.cea.fr [132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id p0PHt0cD021839; Tue, 25 Jan 2011 18:55:00 +0100 Message-ID: <4D3F0E74.5020403@gmail.com> Date: Tue, 25 Jan 2011 18:55:00 +0100 From: Alexandru Petrescu <alexandru.petrescu@gmail.com> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: mext@ietf.org References: <154773479ED2314980CB638A48FC44348334CE4F@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <98A16B2D00B5724F81E80EF1927A0297036BB6@nasanexd01e.na.qualcomm.com> <154773479ED2314980CB638A48FC44348334CFA1@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <98A16B2D00B5724F81E80EF1927A029703A7F6@nasanexd01e.na.qualcomm.com> <154773479ED2314980CB638A48FC44348334D271@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <98A16B2D00B5724F81E80EF1927A029703CA27@nasanexd01e.na.qualcomm.com> <154773479ED2314980CB638A48FC4434833B9F67@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> In-Reply-To: <154773479ED2314980CB638A48FC4434833B9F67@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [MEXT] Support of route optimization in *absence* of HA X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG <mext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/mext> List-Post: <mailto:mext@ietf.org> List-Help: <mailto:mext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 25 Jan 2011 17:52:06 -0000 Thanks for listing these 3 documents. For what it's worth... I think it would be good to decouple the security effort from the HA-less part of the effort. I would thus go further with the proposal to operate on a more general level. Do you have anything against a basic RO HA-less which is security-less as well? If against, then it would make sense to talk _Secure_ HA-less RO RR. If for, then it would make sense to cite http://tools.ietf.org/html/draft-petrescu-autoconf-ra-based-routing-00 and MNPP draft along the 3 documents you cited. I think a basic RO HA-less which is independent of the security mechanism could become a place for adding more security later. For example: add a widely deployed certificate-based https security which secures a link layer (and not CGA, not Mobile IP RR tests). I think that if one tries to further develop existing Mobile IP security mechanisms (CGA, IKE, RR tests) then the goal should be stated in the title, call the effort a security effort, and not simply RO, nor simply RR. For example: return routability tests (called RR in Mobile IP only) exists in other protocols as well (TCP) yet they're not as highly secure as in Mobile IPv6 (nonces, keys). In this sense, in Mobile IP, RR is actually a security effort. RO of Mobile IP does not exist without RR, hence RO is also a security effort. However, it is possible to achieve optimal paths ("route optimization"), without using security. For example, most paths in the Internet are highly optimal in terms of path length, yet very few of them are established securely. I think Mobile IP needs means to offer optimal paths CN-MH (move HA out of the path). However, the effort of offering these paths is not necessarily a security effort. Alex Le 25/01/2011 16:44, Hampel, K Georg (K Georg) a écrit : > All, > > Based on feedback and further thoughts, I propose to permit HA-free > operation on a more general level, i.e. for ALL R/O-solutions that > permit return-routability procedure WITHOUT participation of the HA. > Among those are currently: > > - RFC 4866: Enhanced R/O for MIPv6 > > - RFC 4449: Securing MIPv6 R/O using static shared key > > - draft-ebalard-mext-ipsec-ro-01: Mobile IPv6 IPsec Route > Optimization (IRO) > > Note that HA-free R/O was already anticipated by RFC 4651 (A > Taxonomy and Analysis of Enhancements to Mobile IPv6 Route > Optimization). I think it would add substantial value to MIPv6. RFC > 4651 says: > > > > 2.4. Robustness Enhancements > > > > Route Optimization could conceptually enable continued > communications > > during periods of temporary home-agent unavailability. The > protocol > > defined in RFC 3775 does not achieve this independence, however, as > > the home agent plays an active role in the return-routability > > procedure. Appropriate enhancements could increase the > independence > > from the home agent and thus enable robust Route Optimization even > in > > the absence of the home agent. > > Regards, > > - Georg > > ------------------------------------------------------------------------ > > > *From:*Laganier, Julien [mailto:julienl@qualcomm.com] *Sent:* > Saturday, January 22, 2011 1:47 AM *To:* Hampel, K Georg (K Georg); > mext@ietf.org *Cc:* Klein, Thierry E (Thierry) *Subject:* RE: > Support of route optimization in *absence* of HA > > Georg, > > Regarding #1 I haven’t decided yet I would like the group to discuss > more. The authorization of the MN to use a given HA could be asserted > in a couple of different ways, including but not limited to, a) the > HA only allows creation of initial binding for on-(home)-link MN, b) > the HA only allows creation of initial bindings for on-site MNs, > i.e., CoA in a provider prefix block, and c) the HA has access to a > list of CGA public keys that are authorized to create bindings. > > Regarding #2, if I am not mistaken, at least the 3GPP Evolved Packet > System mandates stateless address autoconfiguration for global > addresses. Only the link-local address is generated from the IID > sent by the GW. > > Best, > > --julien > > *From:*Hampel, K Georg (K Georg) > [mailto:georg.hampel@alcatel-lucent.com] *Sent:* Friday, January 21, > 2011 11:22 AM *To:* Laganier, Julien; Hampel, K Georg (K Georg); > mext@ietf.org *Cc:* Klein, Thierry E (Thierry) *Subject:* RE: > Support of route optimization in *absence* of HA > > Julien, > > Thanks for the info. I like your proposal. CGA provides > cryptographic security without need for trust-relationships, PKI, > pre-shared keys, etc. > > 1) When IPsec is replaced by CGA, MN only proves the authenticity of > its HoA to the HA. It does not authenticate itself in absolute > terms, i.e. via means of strong authentication as required by IPsec > or TLS. How would the HA know that this MN is authorized to use the > HA’s services? > > 2) Do we have any idea to what extend stateless addressing is > “supported”? Does (or will) 3GPP allow stateless addressing? > > -Georg > > ------------------------------------------------------------------------ > > > *From:*Laganier, Julien [mailto:julienl@qualcomm.com] *Sent:* > Friday, January 21, 2011 1:06 PM *To:* Hampel, K Georg (K Georg); > mext@ietf.org *Cc:* Klein, Thierry E (Thierry) *Subject:* RE: > Support of route optimization in *absence* of HA > > Georg, > > Thanks for clarifying, this is what I thought. FWIW, I’ve tried to > extend the RFC 4866 to secure bindings between the MN and the HA in > http://tools.ietf.org/html/draft-laganier-mext-cga-01 > > --julien > > *From:*Hampel, K Georg (K Georg) > [mailto:georg.hampel@alcatel-lucent.com] *Sent:* Thursday, January > 20, 2011 5:25 PM *To:* Laganier, Julien; mext@ietf.org *Cc:* Klein, > Thierry E (Thierry) *Subject:* RE: Support of route optimization in > *absence* of HA > > Julien, > > The intentions of Homeless MIPv6 are similar to those of our > proposal. > > In contrast to Homeless MIPv6, our proposal requires only minimal > upgrades to the present standard and implementation. (Homeless MIPv6 > requires changes to the TCP/UDP and requires AH, for instance). > > Here’s the core idea of HA-free R/O: > > 1)When starting a session, the MN self-declares its current IP > address as the “HoA” for this session. This automatically means that > it resides in its “home network” and can conduct the home test > directly with CN, i.e. no home registration required. > > 2)All further BU/BA signaling is done directly with CN according to > RFC 4866. > > 3)All further signaling with HA is simply omitted. > > Our proposal builds on “enhanced route optimization” (RFC 4866), > which provides a nice security solution for R/O and creates the > ground for HA-free operation. > > Little changes are required: e.g. MN must be able to deregister its > HoA at CN, etc. > > Regards, > > Georg > > ------------------------------------------------------------------------ > > > *From:*Laganier, Julien [mailto:julienl@qualcomm.com] *Sent:* > Thursday, January 20, 2011 4:27 PM *To:* Hampel, K Georg (K Georg); > mext@ietf.org *Cc:* Klein, Thierry E (Thierry) *Subject:* RE: > Support of route optimization in *absence* of HA > > Georg, > > Is it correct that functionally your proposal is similar to Homeless > Mobile IPv6: > > http://tools.ietf.org/html/draft-nikander-mobileip-homelessv6-01 > > Best, > > --julien > > *From:*mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] *On > Behalf Of *Hampel, K Georg (K Georg) *Sent:* Thursday, January 20, > 2011 12:07 PM *To:* mext@ietf.org *Cc:* Hampel, K Georg (K Georg); > Klein, Thierry E (Thierry) *Subject:* [MEXT] Support of route > optimization in *absence* of HA > > All, > > We would like to add a proposal to MEXT that permits the mobile to > engage into route-optimization in *absence* of a home agent. > > Such a feature adds robustness to route optimization in case the HA > is temporarily unavailable. Under some circumstances, route > optimization *without* HA may be beneficial for performance reasons. > Our proposal requires “enhanced route optimization for Mobile IPv6” > (RFC 4866) as pre-requisite. > > We would like to obtain some feedback from the MEXT community via > this mailing list before we submit the proposal as a draft to the > workgroup. For this purpose, we have enclosed a high-level outline > below. Thanks. > > Regards, > > Georg Hampel > > Networking & Networks Domain > > BellLaboratories > > Alcatel-Lucent > > ============================================ > > Proposal: Support of Route-Optimization in Absence of Home Agent > > ABSTRACT: > > The proposal allows the mobile to engage into route optimization > (R/O) in *absence* of a HA. This feature increases robustness when > the HA becomes temporarily unavailable. Under some circumstances, > R/O *without* HA may be beneficial for performance reasons. This > proposal requires “enhanced route optimization for Mobile IPv6” (RFC > 4866) as pre-requisite. > > MOTIVATION: > > In route optimization (R/O), traffic packets are directly exchanged > between hosts without passing the HA. The mobile, however, still has > to interact with the HA. The HA provides (1) location service, (2) a > fallback path in case the direct path breaks, (3) a fallback in case > the correspondent does not support the protocol and (4) security > support for R/O-related signaling (i.e. home test). These functions > come at the following cost: > > ·Handovers may fail when the link to the HA or the HA itself are > down or congested. Mobility is not supported, when the mobile does > not have a HA. > > ·When the mobile starts a session outside of its home network, it > must use a HoA pertaining to its home network even if it engages > into R/O. This requirement adds air-interface overhead due to > mobility headers and processing overhead on the mobile. This upfront > cost incurs even if the mobile does not move during the session. > > ·Signaling handshakes have to be conducted between mobile and HA at > every mobility event. > > Currently, the Mobile IPv6 standard family forces the mobile to bear > these disadvantages in R/O even if the HA functions are not needed. > This specifically applies to scenarios where: > > ·Traffic is based on mobile-initiated requests to public servers > (majority of present mobile internet traffic). The HA’s location > service is not needed for such traffic. Location service may also be > provided by other means such as Dynamic DNS or on application layer > (e.g. SIP registrar). > > ·The fallback path through the HA has little value when it shares > the weakest link with the direct path. Since the weakest link is > typically the wireless link, this situation applies to all scenarios > where only one air interface is available (this is the typical case > rather than the exception). > > ·The mobile may know about the correspondent’s Mobile-IPv6 support > from prior sessions or through means external to the standard. > > ·The mobile applies the CGA-based procedure of RFC 4866, which makes > the HA’s security support for R/O unnecessary. This applies to all > cases where stateless addressing is permitted. > > To increase the flexibility and robustness of route-optimized Mobile > IPv6, we propose to make the HA an *optional* rather than a > *mandatory* feature, i.e. to permit operation without HA. This > proposal requires some additional extensions to the present > standard. > > HIGH-LEVEL OUTLINE > > The extensions build on Enhanced Route Optimization for Mobile IPv6 > (RFC 4866) to guarantee sufficient signaling security. With the > absence of a HA, mobility support in R/O can be provided in the > following manner: > > ·The mobile starts the traffic session from any of its currently > supported IP addresses. The selected IP address automatically takes > the function of the HoA for this session. This has the advantage > that conventional transport is used as long as the mobile does not > move, i.e. mobility headers and CoA-vs-HoA mapping is not needed. The > HoA must have been generated via CGA in compliance with RFC 4866. > > ·The mobile must conduct a “home-test” from this HoA in compliance > with RFC 4866. It may conduct the home-test prior to session > establishment, e.g. to find out if the correspondent supports the > standard. > > ·All binding update handshakes are conducted on the direct path > according to RFC 4866. > > ·Since sessions are always started from a currently supported IP > address, temporally overlapping sessions may use different HoAs. A > multi-homed mobile may also decide to start sessions from different > simultaneously supported IP addresses. There is no principle problem > here. > > ·Opposed to RFC 4866, the mobile need not perform the CoA > registration with the HA. > > ·The mobile must be able to deregister the HoA at the correspondent > in case the HoA is not supported anymore. This ensures that the > correspondent does not send packets to the HoA. After deregistration > of the HoA, the HoA is still used by higher protocol layers of > ongoing sessions. It must still be included in the mobility headers > for these sessions. > > ·When the mobile has HA support and the HA becomes temporarily > unavailable, the mobile simply continues R/O without HA as outlined > in the prior points. > > ·The mobile can publish its IP address in any location service. This > allows other hosts to initiate sessions with the mobile. These > sessions enjoy route-optimized mobility support only if the > published IP address was generated via CGA in compliance with RFC > 4866. > > OPEN ISSUES > > These extensions have to be made compliant with RFC 5648 (multiple > CoA registration), RFC 3963 (NEMO) and others. More discussions are > necessary. > > > > _______________________________________________ MEXT mailing list > MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From georg.hampel@alcatel-lucent.com Tue Jan 25 12:54:44 2011 Return-Path: <georg.hampel@alcatel-lucent.com> X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C91F3A685C for <mext@core3.amsl.com>; Tue, 25 Jan 2011 12:54:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id syb371G6VLDu for <mext@core3.amsl.com>; Tue, 25 Jan 2011 12:54:42 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id 604123A6838 for <mext@ietf.org>; Tue, 25 Jan 2011 12:54:41 -0800 (PST) Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id p0PKvbKn002949 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 25 Jan 2011 14:57:37 -0600 (CST) Received: from USNAVSXCHHUB01.ndc.alcatel-lucent.com (usnavsxchhub01.ndc.alcatel-lucent.com [135.3.39.110]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p0PKvROa012329 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 25 Jan 2011 14:57:37 -0600 Received: from USNAVSXCHMBSA2.ndc.alcatel-lucent.com ([135.3.39.127]) by USNAVSXCHHUB01.ndc.alcatel-lucent.com ([135.3.39.110]) with mapi; Tue, 25 Jan 2011 14:05:52 -0600 From: "Hampel, K Georg (K Georg)" <georg.hampel@alcatel-lucent.com> To: Alexandru Petrescu <alexandru.petrescu@gmail.com>, "mext@ietf.org" <mext@ietf.org> Date: Tue, 25 Jan 2011 14:05:50 -0600 Thread-Topic: [MEXT] Support of route optimization in *absence* of HA Thread-Index: Acu8uQGBGzm03iKDREqTqAZAOGpU2QAC6LfQ Message-ID: <154773479ED2314980CB638A48FC4434833BA115@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> References: <154773479ED2314980CB638A48FC44348334CE4F@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <98A16B2D00B5724F81E80EF1927A0297036BB6@nasanexd01e.na.qualcomm.com> <154773479ED2314980CB638A48FC44348334CFA1@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <98A16B2D00B5724F81E80EF1927A029703A7F6@nasanexd01e.na.qualcomm.com> <154773479ED2314980CB638A48FC44348334D271@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <98A16B2D00B5724F81E80EF1927A029703CA27@nasanexd01e.na.qualcomm.com> <154773479ED2314980CB638A48FC4434833B9F67@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <4D3F0E74.5020403@gmail.com> In-Reply-To: <4D3F0E74.5020403@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.9 Subject: Re: [MEXT] Support of route optimization in *absence* of HA X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG <mext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/mext> List-Post: <mailto:mext@ietf.org> List-Help: <mailto:mext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 25 Jan 2011 20:54:44 -0000 Hi Alex, I think there are principle concerns about host-based mobility solutions wi= thout proper security (see RFC 4225 for instance). HA-free RO without secur= ity would fall into that space. Obviously, it would be of advantage to keep= HA-free RO as general as possible, i.e. without relying on a *specific* se= curity solution. Regarding mobile routers + optimal paths: Shouldn't this be covered by rout= e-optimized NEMO? Georg -----Original Message----- From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of Ale= xandru Petrescu Sent: Tuesday, January 25, 2011 12:55 PM To: mext@ietf.org Subject: Re: [MEXT] Support of route optimization in *absence* of HA Thanks for listing these 3 documents. For what it's worth... I think it would be good to decouple the security effort from the HA-less part of the effort. I would thus go further with the proposal to operate on a more general level. Do you have anything against a basic RO HA-less which is security-less as well? If against, then it would make sense to talk _Secure_ HA-less RO RR. If for, then it would make sense to cite http://tools.ietf.org/html/draft-petrescu-autoconf-ra-based-routing-00 and MNPP draft along the 3 documents you cited. I think a basic RO HA-less which is independent of the security mechanism could become a place for adding more security later. For example: add a widely deployed certificate-based https security which secures a link layer (and not CGA, not Mobile IP RR tests). I think that if one tries to further develop existing Mobile IP security mechanisms (CGA, IKE, RR tests) then the goal should be stated in the title, call the effort a security effort, and not simply RO, nor simply RR. For example: return routability tests (called RR in Mobile IP only) exists in other protocols as well (TCP) yet they're not as highly secure as in Mobile IPv6 (nonces, keys). In this sense, in Mobile IP, RR is actually a security effort. RO of Mobile IP does not exist without RR, hence RO is also a security effort. However, it is possible to achieve optimal paths ("route optimization"), without using security. For example, most paths in the Internet are highly optimal in terms of path length, yet very few of them are established securely. I think Mobile IP needs means to offer optimal paths CN-MH (move HA out of the path). However, the effort of offering these paths is not necessarily a security effort. Alex Le 25/01/2011 16:44, Hampel, K Georg (K Georg) a =E9crit : > All, > > Based on feedback and further thoughts, I propose to permit HA-free > operation on a more general level, i.e. for ALL R/O-solutions that > permit return-routability procedure WITHOUT participation of the HA. > Among those are currently: > > - RFC 4866: Enhanced R/O for MIPv6 > > - RFC 4449: Securing MIPv6 R/O using static shared key > > - draft-ebalard-mext-ipsec-ro-01: Mobile IPv6 IPsec Route > Optimization (IRO) > > Note that HA-free R/O was already anticipated by RFC 4651 (A > Taxonomy and Analysis of Enhancements to Mobile IPv6 Route > Optimization). I think it would add substantial value to MIPv6. RFC > 4651 says: > > > > 2.4. Robustness Enhancements > > > > Route Optimization could conceptually enable continued > communications > > during periods of temporary home-agent unavailability. The > protocol > > defined in RFC 3775 does not achieve this independence, however, as > > the home agent plays an active role in the return-routability > > procedure. Appropriate enhancements could increase the > independence > > from the home agent and thus enable robust Route Optimization even > in > > the absence of the home agent. > > Regards, > > - Georg > > ------------------------------------------------------------------------ > > > *From:*Laganier, Julien [mailto:julienl@qualcomm.com] *Sent:* > Saturday, January 22, 2011 1:47 AM *To:* Hampel, K Georg (K Georg); > mext@ietf.org *Cc:* Klein, Thierry E (Thierry) *Subject:* RE: > Support of route optimization in *absence* of HA > > Georg, > > Regarding #1 I haven't decided yet I would like the group to discuss > more. The authorization of the MN to use a given HA could be asserted > in a couple of different ways, including but not limited to, a) the > HA only allows creation of initial binding for on-(home)-link MN, b) > the HA only allows creation of initial bindings for on-site MNs, > i.e., CoA in a provider prefix block, and c) the HA has access to a > list of CGA public keys that are authorized to create bindings. > > Regarding #2, if I am not mistaken, at least the 3GPP Evolved Packet > System mandates stateless address autoconfiguration for global > addresses. Only the link-local address is generated from the IID > sent by the GW. > > Best, > > --julien > > *From:*Hampel, K Georg (K Georg) > [mailto:georg.hampel@alcatel-lucent.com] *Sent:* Friday, January 21, > 2011 11:22 AM *To:* Laganier, Julien; Hampel, K Georg (K Georg); > mext@ietf.org *Cc:* Klein, Thierry E (Thierry) *Subject:* RE: > Support of route optimization in *absence* of HA > > Julien, > > Thanks for the info. I like your proposal. CGA provides > cryptographic security without need for trust-relationships, PKI, > pre-shared keys, etc. > > 1) When IPsec is replaced by CGA, MN only proves the authenticity of > its HoA to the HA. It does not authenticate itself in absolute > terms, i.e. via means of strong authentication as required by IPsec > or TLS. How would the HA know that this MN is authorized to use the > HA's services? > > 2) Do we have any idea to what extend stateless addressing is > "supported"? Does (or will) 3GPP allow stateless addressing? > > -Georg > > ------------------------------------------------------------------------ > > > *From:*Laganier, Julien [mailto:julienl@qualcomm.com] *Sent:* > Friday, January 21, 2011 1:06 PM *To:* Hampel, K Georg (K Georg); > mext@ietf.org *Cc:* Klein, Thierry E (Thierry) *Subject:* RE: > Support of route optimization in *absence* of HA > > Georg, > > Thanks for clarifying, this is what I thought. FWIW, I've tried to > extend the RFC 4866 to secure bindings between the MN and the HA in > http://tools.ietf.org/html/draft-laganier-mext-cga-01 > > --julien > > *From:*Hampel, K Georg (K Georg) > [mailto:georg.hampel@alcatel-lucent.com] *Sent:* Thursday, January > 20, 2011 5:25 PM *To:* Laganier, Julien; mext@ietf.org *Cc:* Klein, > Thierry E (Thierry) *Subject:* RE: Support of route optimization in > *absence* of HA > > Julien, > > The intentions of Homeless MIPv6 are similar to those of our > proposal. > > In contrast to Homeless MIPv6, our proposal requires only minimal > upgrades to the present standard and implementation. (Homeless MIPv6 > requires changes to the TCP/UDP and requires AH, for instance). > > Here's the core idea of HA-free R/O: > > 1)When starting a session, the MN self-declares its current IP > address as the "HoA" for this session. This automatically means that > it resides in its "home network" and can conduct the home test > directly with CN, i.e. no home registration required. > > 2)All further BU/BA signaling is done directly with CN according to > RFC 4866. > > 3)All further signaling with HA is simply omitted. > > Our proposal builds on "enhanced route optimization" (RFC 4866), > which provides a nice security solution for R/O and creates the > ground for HA-free operation. > > Little changes are required: e.g. MN must be able to deregister its > HoA at CN, etc. > > Regards, > > Georg > > ------------------------------------------------------------------------ > > > *From:*Laganier, Julien [mailto:julienl@qualcomm.com] *Sent:* > Thursday, January 20, 2011 4:27 PM *To:* Hampel, K Georg (K Georg); > mext@ietf.org *Cc:* Klein, Thierry E (Thierry) *Subject:* RE: > Support of route optimization in *absence* of HA > > Georg, > > Is it correct that functionally your proposal is similar to Homeless > Mobile IPv6: > > http://tools.ietf.org/html/draft-nikander-mobileip-homelessv6-01 > > Best, > > --julien > > *From:*mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] *On > Behalf Of *Hampel, K Georg (K Georg) *Sent:* Thursday, January 20, > 2011 12:07 PM *To:* mext@ietf.org *Cc:* Hampel, K Georg (K Georg); > Klein, Thierry E (Thierry) *Subject:* [MEXT] Support of route > optimization in *absence* of HA > > All, > > We would like to add a proposal to MEXT that permits the mobile to > engage into route-optimization in *absence* of a home agent. > > Such a feature adds robustness to route optimization in case the HA > is temporarily unavailable. Under some circumstances, route > optimization *without* HA may be beneficial for performance reasons. > Our proposal requires "enhanced route optimization for Mobile IPv6" > (RFC 4866) as pre-requisite. > > We would like to obtain some feedback from the MEXT community via > this mailing list before we submit the proposal as a draft to the > workgroup. For this purpose, we have enclosed a high-level outline > below. Thanks. > > Regards, > > Georg Hampel > > Networking & Networks Domain > > BellLaboratories > > Alcatel-Lucent > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > Proposal: Support of Route-Optimization in Absence of Home Agent > > ABSTRACT: > > The proposal allows the mobile to engage into route optimization > (R/O) in *absence* of a HA. This feature increases robustness when > the HA becomes temporarily unavailable. Under some circumstances, > R/O *without* HA may be beneficial for performance reasons. This > proposal requires "enhanced route optimization for Mobile IPv6" (RFC > 4866) as pre-requisite. > > MOTIVATION: > > In route optimization (R/O), traffic packets are directly exchanged > between hosts without passing the HA. The mobile, however, still has > to interact with the HA. The HA provides (1) location service, (2) a > fallback path in case the direct path breaks, (3) a fallback in case > the correspondent does not support the protocol and (4) security > support for R/O-related signaling (i.e. home test). These functions > come at the following cost: > > =B7Handovers may fail when the link to the HA or the HA itself are > down or congested. Mobility is not supported, when the mobile does > not have a HA. > > =B7When the mobile starts a session outside of its home network, it > must use a HoA pertaining to its home network even if it engages > into R/O. This requirement adds air-interface overhead due to > mobility headers and processing overhead on the mobile. This upfront > cost incurs even if the mobile does not move during the session. > > =B7Signaling handshakes have to be conducted between mobile and HA at > every mobility event. > > Currently, the Mobile IPv6 standard family forces the mobile to bear > these disadvantages in R/O even if the HA functions are not needed. > This specifically applies to scenarios where: > > =B7Traffic is based on mobile-initiated requests to public servers > (majority of present mobile internet traffic). The HA's location > service is not needed for such traffic. Location service may also be > provided by other means such as Dynamic DNS or on application layer > (e.g. SIP registrar). > > =B7The fallback path through the HA has little value when it shares > the weakest link with the direct path. Since the weakest link is > typically the wireless link, this situation applies to all scenarios > where only one air interface is available (this is the typical case > rather than the exception). > > =B7The mobile may know about the correspondent's Mobile-IPv6 support > from prior sessions or through means external to the standard. > > =B7The mobile applies the CGA-based procedure of RFC 4866, which makes > the HA's security support for R/O unnecessary. This applies to all > cases where stateless addressing is permitted. > > To increase the flexibility and robustness of route-optimized Mobile > IPv6, we propose to make the HA an *optional* rather than a > *mandatory* feature, i.e. to permit operation without HA. This > proposal requires some additional extensions to the present > standard. > > HIGH-LEVEL OUTLINE > > The extensions build on Enhanced Route Optimization for Mobile IPv6 > (RFC 4866) to guarantee sufficient signaling security. With the > absence of a HA, mobility support in R/O can be provided in the > following manner: > > =B7The mobile starts the traffic session from any of its currently > supported IP addresses. The selected IP address automatically takes > the function of the HoA for this session. This has the advantage > that conventional transport is used as long as the mobile does not > move, i.e. mobility headers and CoA-vs-HoA mapping is not needed. The > HoA must have been generated via CGA in compliance with RFC 4866. > > =B7The mobile must conduct a "home-test" from this HoA in compliance > with RFC 4866. It may conduct the home-test prior to session > establishment, e.g. to find out if the correspondent supports the > standard. > > =B7All binding update handshakes are conducted on the direct path > according to RFC 4866. > > =B7Since sessions are always started from a currently supported IP > address, temporally overlapping sessions may use different HoAs. A > multi-homed mobile may also decide to start sessions from different > simultaneously supported IP addresses. There is no principle problem > here. > > =B7Opposed to RFC 4866, the mobile need not perform the CoA > registration with the HA. > > =B7The mobile must be able to deregister the HoA at the correspondent > in case the HoA is not supported anymore. This ensures that the > correspondent does not send packets to the HoA. After deregistration > of the HoA, the HoA is still used by higher protocol layers of > ongoing sessions. It must still be included in the mobility headers > for these sessions. > > =B7When the mobile has HA support and the HA becomes temporarily > unavailable, the mobile simply continues R/O without HA as outlined > in the prior points. > > =B7The mobile can publish its IP address in any location service. This > allows other hosts to initiate sessions with the mobile. These > sessions enjoy route-optimized mobility support only if the > published IP address was generated via CGA in compliance with RFC > 4866. > > OPEN ISSUES > > These extensions have to be made compliant with RFC 5648 (multiple > CoA registration), RFC 3963 (NEMO) and others. More discussions are > necessary. > > > > _______________________________________________ MEXT mailing list > MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From julienl@qualcomm.com Tue Jan 25 14:45:58 2011 Return-Path: <julienl@qualcomm.com> X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 953A33A68BD for <mext@core3.amsl.com>; Tue, 25 Jan 2011 14:45:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.362 X-Spam-Level: X-Spam-Status: No, score=-106.362 tagged_above=-999 required=5 tests=[AWL=0.237, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aboqrFqrPz-l for <mext@core3.amsl.com>; Tue, 25 Jan 2011 14:45:57 -0800 (PST) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 48DEA3A68A2 for <mext@ietf.org>; Tue, 25 Jan 2011 14:45:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1295995736; x=1327531736; h=from:to:cc:subject:thread-topic:thread-index:date: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: x-originating-ip:content-type:content-transfer-encoding: mime-version; z=From:=20"Laganier,=20Julien"=20<julienl@qualcomm.com> |To:=20"Basavaraj.Patil@nokia.com"=20<Basavaraj.Patil@nok ia.com>,=0D=0A=09"arno@natisbad.org"=20<arno@natisbad.org >,=20"jan@go6.si"=20<jan@go6.si>|CC:=20"mext@ietf.org"=20 <mext@ietf.org>|Subject:=20RE:=20[MEXT]=20Call=20for=20WG =20adoption=20of=20I-D:=0D=0A=20draft-korhonen-mext-mip6- altsec|Thread-Topic:=20[MEXT]=20Call=20for=20WG=20adoptio n=20of=20I-D:=0D=0A=20draft-korhonen-mext-mip6-altsec |Thread-Index:=20AQHLvBKaOXOYKRxBgE2Iml9N3D281pPiSosQ |Date:=20Tue,=2025=20Jan=202011=2022:48:54=20+0000 |Message-ID:=20<98A16B2D00B5724F81E80EF1927A029703E3FB@na sanexd01e.na.qualcomm.com>|References:=20<878vyarmku.fsf@ natisbad.org>=0D=0A=20<C963527A.D013%basavaraj.patil@noki a.com>|In-Reply-To:=20<C963527A.D013%basavaraj.patil@noki a.com>|Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|x-originating-ip: =20[172.30.39.5]|Content-Type:=20text/plain=3B=20charset =3D"us-ascii"|Content-Transfer-Encoding:=20quoted-printab le|MIME-Version:=201.0; bh=XJTaWmljJusiimIXy7a3mLzMU/p3KGCa/5612E2gUTg=; b=EwM8VYDLz7He7J0PlNT3fyYaZyasRbPxhOK5mThsmPr6aP+osTVqE19s X0cWMFrUzYjaIXccAQz2u2KbBxxultte38Az6gZwGL76XPLn+/tUGbR5r x0l52DZiRu/1+yXUAy5O/y1VoEqu68yHTo4MbLG6EOMLzj/IhKKa5OVaP 0=; X-IronPort-AV: E=McAfee;i="5400,1158,6237"; a="71750182" Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by wolverine02.qualcomm.com with ESMTP; 25 Jan 2011 14:48:56 -0800 X-IronPort-AV: E=Sophos;i="4.60,374,1291622400"; d="scan'208";a="24808699" Received: from nasanexhc05.na.qualcomm.com ([172.30.48.2]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/AES128-SHA; 25 Jan 2011 14:48:55 -0800 Received: from NASANEXD01E.na.qualcomm.com ([fe80::6555:8c37:4ee3:efc4]) by nasanexhc05.na.qualcomm.com ([::1]) with mapi id 14.01.0218.012; Tue, 25 Jan 2011 14:48:55 -0800 From: "Laganier, Julien" <julienl@qualcomm.com> To: "Basavaraj.Patil@nokia.com" <Basavaraj.Patil@nokia.com>, "arno@natisbad.org" <arno@natisbad.org>, "jan@go6.si" <jan@go6.si> Thread-Topic: [MEXT] Call for WG adoption of I-D: draft-korhonen-mext-mip6-altsec Thread-Index: AQHLvBKaOXOYKRxBgE2Iml9N3D281pPiSosQ Date: Tue, 25 Jan 2011 22:48:54 +0000 Message-ID: <98A16B2D00B5724F81E80EF1927A029703E3FB@nasanexd01e.na.qualcomm.com> References: <878vyarmku.fsf@natisbad.org> <C963527A.D013%basavaraj.patil@nokia.com> In-Reply-To: <C963527A.D013%basavaraj.patil@nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.30.39.5] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mext@ietf.org" <mext@ietf.org> Subject: Re: [MEXT] Call for WG adoption of I-D: draft-korhonen-mext-mip6-altsec X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG <mext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/mext> List-Post: <mailto:mext@ietf.org> List-Help: <mailto:mext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 25 Jan 2011 22:45:58 -0000 Hi Raj, =20 > Inline: >=20 > On 1/24/11 3:58 PM, "ext Arnaud Ebalard" <arno@natisbad.org> wrote: >=20 > > > >To me, what the draft describes is a patchwork based on MIPv6, ESP and > >TLS. Instead of building on top of those protocols (read modularity > and > >interoperability), it reuses (hijacks) various blocks of associated > >standards in a non-modular way. For instance, one has to reimplement > ESP > >in userspace to support the protocol. >=20 > We are specifying an encapsulation method in the I-D. To say that one > has to reimplement ESP in userspace is incorrect. The encapsulation format you have in the I-D is: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : IPv4 or IPv6 header (src-addr=3DXa, dst-addr=3DYa) : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : UDP header (src-port=3DXp,dst-port=3DYp) : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ------ |PType=3D8| SPI | ^Int. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov- | Sequence Number | |ered +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ---- | Payload Data* (variable) | | ^ : : | | | | |Conf. + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov- | | Padding (0-255 bytes) | |ered* +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | Pad Length | Next Header | v v +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ------ | Integrity Check Value-ICV (variable) | : : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 7: UDP Encapsulated Binding Management Message Format Which looks like a copy/paste of the ESP specification [RFC4303]: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---- | Security Parameters Index (SPI) | ^Int. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov- | Sequence Number | |ered +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ---- | Payload Data* (variable) | | ^ ~ ~ | | | | |Conf. + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov- | | Padding (0-255 bytes) | |ered* +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | Pad Length | Next Header | v v +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ------ | Integrity Check Value-ICV (variable) | ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1. Top-Level Format of an ESP Packet So the question is: Is your intent to provide a UDP encapsulation format fo= r the already specified ESP protocol, or to provide an alternative encapsul= ation format to ESP? --julien From yokota@kddilabs.jp Tue Jan 25 17:39:09 2011 Return-Path: <yokota@kddilabs.jp> X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F1F493A6906 for <mext@core3.amsl.com>; Tue, 25 Jan 2011 17:39:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MRt0lObfLSNb for <mext@core3.amsl.com>; Tue, 25 Jan 2011 17:39:07 -0800 (PST) Received: from mandala.kddilabs.jp (mandala.kddilabs.jp [IPv6:2001:200:601:12::16]) by core3.amsl.com (Postfix) with ESMTP id ABC3D3A6905 for <mext@ietf.org>; Tue, 25 Jan 2011 17:39:05 -0800 (PST) Received: from localhost (mandala.kddilabs.jp [127.0.0.1]) by mandala.kddilabs.jp (Postfix) with ESMTP id 71770174810C for <mext@ietf.org>; Wed, 26 Jan 2011 10:42:00 +0900 (JST) X-Virus-Scanned: amavisd-new at kddilabs.jp Received: from mandala.kddilabs.jp ([127.0.0.1]) by localhost (mandala.kddilabs.jp [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5no+-TzKoqMo for <mext@ietf.org>; Wed, 26 Jan 2011 10:41:58 +0900 (JST) Received: from ultra.mip.kddilabs.jp (ultra.mip.kddilabs.jp [172.19.90.145]) by mandala.kddilabs.jp (Postfix) with ESMTP id D3B23174810A for <mext@ietf.org>; Wed, 26 Jan 2011 10:41:58 +0900 (JST) Received: from [127.0.0.1] (yokotaiMac.mn.mip.kddilabs.jp [172.19.90.26]) by ultra.mip.kddilabs.jp (Postfix) with ESMTP id 217941B85F for <mext@ietf.org>; Wed, 26 Jan 2011 10:41:55 +0900 (JST) Message-ID: <4D3F7BDF.1040207@kddilabs.jp> Date: Wed, 26 Jan 2011 10:41:51 +0900 From: Hidetoshi Yokota <yokota@kddilabs.jp> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: mext@ietf.org References: <4D3DD426.6080107@it.uc3m.es> <4D3DE564.30505@go6.si> In-Reply-To: <4D3DE564.30505@go6.si> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Subject: Re: [MEXT] Call for WG adoption of I-D: draft-korhonen-mext-mip6-altsec X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG <mext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/mext> List-Post: <mailto:mext@ietf.org> List-Help: <mailto:mext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 26 Jan 2011 01:39:09 -0000 Hi, I also tested the implementation, which worked very well, succeeding in setting up an inter-continental MIPv6 connection without any hassle. I believe that the I-D can resolve one of the deployment issues and thus support it as a WG draft. I hope to see it really deployed in commercial mobile networks and devices. Regards, -- Hidetoshi (2011/01/25 5:47), Jan Zorz @ go6.si wrote: > On 1/24/11 8:33 PM, marcelo bagnulo braun wrote: >> The ID has had 3 reviews as we require. >> So, we are now ready to ask the WG if they think we should adopt the >> document. >> >> Please express your opinion before monday 31st jan. > > Well, I think this I-D should go forward as it solves some issues with > current thinking of mobile part of the stack, and it has an > implementation, that works fine. > > Regards, Jan Zorz > go6.si > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > > > From jouni.nospam@gmail.com Tue Jan 25 23:52:13 2011 Return-Path: <jouni.nospam@gmail.com> X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 428E728C0D9 for <mext@core3.amsl.com>; Tue, 25 Jan 2011 23:52:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.449 X-Spam-Level: X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZUFsZk5Rru2W for <mext@core3.amsl.com>; Tue, 25 Jan 2011 23:52:12 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id AA1B228C0D7 for <mext@ietf.org>; Tue, 25 Jan 2011 23:52:11 -0800 (PST) Received: by bwz12 with SMTP id 12so1279164bwz.31 for <mext@ietf.org>; Tue, 25 Jan 2011 23:55:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=Isr/sycFKQ8ulwrsgCRokqdsTQ9xHEB7THJf1ovR6vs=; b=Hu+dpNeDrjFhhzd/WFCL+u5pRMEaSjPeC/2E5GLw5GRcwz5YeHFvE0teRyCMtn4iol WMS2cahyiF7+YWWkPHsYs7yTG+nL90AlvBghmX2ly/eEoeetFrHlmtuRlsUkkQScwg0q BL0N2ooiuVAx64XU3Tho57yG8bftpctQD7rD8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=bBuGrpcOp5AhoieHR5mG2tqn2Mod/Q/m5gx1AvX9gkFn8HqPvEkxan6IjGzs1ISvXX IhmZlHAp+qPq0pntBGD5xHS/BOLz/YX1xIgasWe3IWQaY4EpBT/7zi/myp2yyIHVhNQl ZgHWKiv91xJNwvE9WgMUMd8HMtRxE8MKJat58= Received: by 10.204.112.147 with SMTP id w19mr76484bkp.137.1296028510532; Tue, 25 Jan 2011 23:55:10 -0800 (PST) Received: from a88-112-142-31.elisa-laajakaista.fi (a88-112-142-31.elisa-laajakaista.fi [88.112.142.31]) by mx.google.com with ESMTPS id a17sm7283386bku.23.2011.01.25.23.55.08 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 25 Jan 2011 23:55:09 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: jouni korhonen <jouni.nospam@gmail.com> In-Reply-To: <98A16B2D00B5724F81E80EF1927A029703E3FB@nasanexd01e.na.qualcomm.com> Date: Wed, 26 Jan 2011 09:55:07 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <06CCEF13-4E11-474D-A25E-C1425D5B520A@gmail.com> References: <878vyarmku.fsf@natisbad.org> <C963527A.D013%basavaraj.patil@nokia.com> <98A16B2D00B5724F81E80EF1927A029703E3FB@nasanexd01e.na.qualcomm.com> To: "Laganier, Julien" <julienl@qualcomm.com> X-Mailer: Apple Mail (2.1078) Cc: "mext@ietf.org" <mext@ietf.org>, "jan@go6.si" <jan@go6.si>, "Basavaraj.Patil@nokia.com" <Basavaraj.Patil@nokia.com> Subject: Re: [MEXT] Call for WG adoption of I-D: draft-korhonen-mext-mip6-altsec X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG <mext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/mext> List-Post: <mailto:mext@ietf.org> List-Help: <mailto:mext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 26 Jan 2011 07:52:13 -0000 Few things. The draft already states that "The Padding, Pad Length, Next Header and ICV fields follow the rules of Section 2.4 to 2.8 of = [RFC4303] unless otherwise stated in this document." So, we follow the ESP format but feel no shame on changing it if we see a reason to do so. The reason why we chose to do it like this was two fold: 1) some ciphers etc when used would need ~equivalent encapsulation anyway. 2) if we had come up with our very own format the question on the list would have been "why not using RFC4303 encapsulation format". Actually.. the latter already happened offline. - Jouni On Jan 26, 2011, at 12:48 AM, Laganier, Julien wrote: > Hi Raj, >=20 >> Inline: >>=20 >> On 1/24/11 3:58 PM, "ext Arnaud Ebalard" <arno@natisbad.org> wrote: >>=20 >>>=20 >>> To me, what the draft describes is a patchwork based on MIPv6, ESP = and >>> TLS. Instead of building on top of those protocols (read modularity >> and >>> interoperability), it reuses (hijacks) various blocks of associated >>> standards in a non-modular way. For instance, one has to reimplement >> ESP >>> in userspace to support the protocol. >>=20 >> We are specifying an encapsulation method in the I-D. To say that one >> has to reimplement ESP in userspace is incorrect. >=20 > The encapsulation format you have in the I-D is: >=20 > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > : IPv4 or IPv6 header (src-addr=3DXa, dst-addr=3DYa) : > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > : UDP header (src-port=3DXp,dst-port=3DYp) : > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = ------ > |PType=3D8| SPI | = ^Int. > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = |Cov- > | Sequence Number | = |ered > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | = ---- > | Payload Data* (variable) | | = ^ > : : | = | > | | = |Conf. > + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = |Cov- > | | Padding (0-255 bytes) | = |ered* > +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | = | > | | Pad Length | Next Header | v = v > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = ------ > | Integrity Check Value-ICV (variable) | > : : > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 > Figure 7: UDP Encapsulated Binding Management Message Format >=20 > Which looks like a copy/paste of the ESP specification [RFC4303]: >=20 > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---- > | Security Parameters Index (SPI) | = ^Int. > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = |Cov- > | Sequence Number | = |ered > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | = ---- > | Payload Data* (variable) | | = ^ > ~ ~ | = | > | | = |Conf. > + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = |Cov- > | | Padding (0-255 bytes) | = |ered* > +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | = | > | | Pad Length | Next Header | v = v > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = ------ > | Integrity Check Value-ICV (variable) | > ~ ~ > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 > Figure 1. Top-Level Format of an ESP Packet >=20 >=20 > So the question is: Is your intent to provide a UDP encapsulation = format for the already specified ESP protocol, or to provide an = alternative encapsulation format to ESP? >=20 > --julien > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext From antti.makela@aalto.fi Wed Jan 26 03:18:35 2011 Return-Path: <antti.makela@aalto.fi> X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8994F3A6989 for <mext@core3.amsl.com>; Wed, 26 Jan 2011 03:18:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WcsUBE8I4CDk for <mext@core3.amsl.com>; Wed, 26 Jan 2011 03:18:33 -0800 (PST) Received: from mx03.aalto.fi (mx03.aalto.fi [130.233.222.102]) by core3.amsl.com (Postfix) with ESMTP id 349493A6830 for <mext@ietf.org>; Wed, 26 Jan 2011 03:18:32 -0800 (PST) Received: from mx03.aalto.fi (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 30B1E288F0; Wed, 26 Jan 2011 13:21:32 +0200 (EET) Received: from EXHUB04.org.aalto.fi (ex-hub04.org.aalto.fi [130.233.222.117]) by mx03.aalto.fi (Postfix) with ESMTP id E5AFF288F6; Wed, 26 Jan 2011 13:21:31 +0200 (EET) Received: from EXMDB08.org.aalto.fi ([169.254.8.40]) by EXHUB04.org.aalto.fi ([130.233.222.117]) with mapi; Wed, 26 Jan 2011 13:21:31 +0200 From: =?Windows-1252?Q?M=E4kel=E4_Antti?= <antti.makela@aalto.fi> To: Alexandru Petrescu <alexandru.petrescu@gmail.com>, "mext@ietf.org" <mext@ietf.org> Thread-Topic: [MEXT] Support of route optimization in *absence* of HA Thread-Index: AQHLvLj8UEf1urDUyUWHHSacIaQ4WJPjE1YF Date: Wed, 26 Jan 2011 11:21:31 +0000 Message-ID: <64FACAB831EEEB418F27A18FE09095243CF932C6@EXMDB08.org.aalto.fi> References: <154773479ED2314980CB638A48FC44348334CE4F@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <98A16B2D00B5724F81E80EF1927A0297036BB6@nasanexd01e.na.qualcomm.com> <154773479ED2314980CB638A48FC44348334CFA1@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <98A16B2D00B5724F81E80EF1927A029703A7F6@nasanexd01e.na.qualcomm.com> <154773479ED2314980CB638A48FC44348334D271@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <98A16B2D00B5724F81E80EF1927A029703CA27@nasanexd01e.na.qualcomm.com> <154773479ED2314980CB638A48FC4434833B9F67@USNAVSXCHMBSA2.ndc.alcatel-lucent.com>, <31821_1295978112_4D3F0E80_31821_2069_1_4D3F0E74.5020403@gmail.com> In-Reply-To: <31821_1295978112_4D3F0E80_31821_2069_1_4D3F0E74.5020403@gmail.com> Accept-Language: en-US, fi-FI Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [MEXT] Support of route optimization in *absence* of HA X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG <mext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/mext> List-Post: <mailto:mext@ietf.org> List-Help: <mailto:mext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 26 Jan 2011 11:18:35 -0000 Hi, HA-less RO sounds like a very interesting effort. The resemblances to ad-= hoc routing are quite large though. From how I understood the draft, the us= e case and primary scenario is the situation where the mobile node has most= ly outbound traffic, and simply needs to make sure that sessions don't get = interrupted if the node moves. I agree that security should probably be made "modular" in the sense that= you are free to secure the RO with any way you choose, or even without any= security at all (in a trusted environment). In essence the current suggestion sounds like: Mobile Node chooses a "HoA" from one of the current interface addresses a= nd acts as it's in "home network" Starts communicating with CN If node moves, tell the CN via RO procedure that me, previously at home, = now have a CoA that corresponds to my HoA Any new sessions should use the new network's address as "HoA", and if th= e session to the CN ends, the RO should be torn down as well. My primary concerns with this basic idea are related to persistent sessio= ns - some application connecting to the CN and keeping the same connection,= so the MN can never relinquish the HoA. This leads to the philosophical is= sue about if you are a mobile node and using such "ad-hoc" HoAs that you ha= ve picked up on the way, do you have the permission to make such address mo= bile (take it out of the network)? In an environment with HA, the HA gives you explicit permission that yes,= you can use this address, from my network, owned by me, to communicate wit= h rest of the world. Without HA, considering whatever network you happen to be in when first c= ommunicating to a CN your "home network" - should the MN be allowed to move= the HoA away? For how long? Until DHCPv6 lease expires? Until RA timer expires? When? -- - Antti M=E4kel=E4 | Researcher - - Department of communications and networking - - Aalto University - ________________________________________ From: mext-bounces@ietf.org [mext-bounces@ietf.org] on behalf of Alexandru = Petrescu [alexandru.petrescu@gmail.com] Sent: Tuesday, January 25, 2011 19:55 To: mext@ietf.org Subject: Re: [MEXT] Support of route optimization in *absence* of HA Thanks for listing these 3 documents. For what it's worth... I think it would be good to decouple the security effort from the HA-less part of the effort. I would thus go further with the proposal to operate on a more general level. Do you have anything against a basic RO HA-less which is security-less as well? If against, then it would make sense to talk _Secure_ HA-less RO RR. If for, then it would make sense to cite http://tools.ietf.org/html/draft-petrescu-autoconf-ra-based-routing-00 and MNPP draft along the 3 documents you cited. I think a basic RO HA-less which is independent of the security mechanism could become a place for adding more security later. For example: add a widely deployed certificate-based https security which secures a link layer (and not CGA, not Mobile IP RR tests). I think that if one tries to further develop existing Mobile IP security mechanisms (CGA, IKE, RR tests) then the goal should be stated in the title, call the effort a security effort, and not simply RO, nor simply RR. For example: return routability tests (called RR in Mobile IP only) exists in other protocols as well (TCP) yet they're not as highly secure as in Mobile IPv6 (nonces, keys). In this sense, in Mobile IP, RR is actually a security effort. RO of Mobile IP does not exist without RR, hence RO is also a security effort. However, it is possible to achieve optimal paths ("route optimization"), without using security. For example, most paths in the Internet are highly optimal in terms of path length, yet very few of them are established securely. I think Mobile IP needs means to offer optimal paths CN-MH (move HA out of the path). However, the effort of offering these paths is not necessarily a security effort. Alex Le 25/01/2011 16:44, Hampel, K Georg (K Georg) a =E9crit : > All, > > Based on feedback and further thoughts, I propose to permit HA-free > operation on a more general level, i.e. for ALL R/O-solutions that > permit return-routability procedure WITHOUT participation of the HA. > Among those are currently: > > - RFC 4866: Enhanced R/O for MIPv6 > > - RFC 4449: Securing MIPv6 R/O using static shared key > > - draft-ebalard-mext-ipsec-ro-01: Mobile IPv6 IPsec Route > Optimization (IRO) > > Note that HA-free R/O was already anticipated by RFC 4651 (A > Taxonomy and Analysis of Enhancements to Mobile IPv6 Route > Optimization). I think it would add substantial value to MIPv6. RFC > 4651 says: > > > > 2.4. Robustness Enhancements > > > > Route Optimization could conceptually enable continued > communications > > during periods of temporary home-agent unavailability. The > protocol > > defined in RFC 3775 does not achieve this independence, however, as > > the home agent plays an active role in the return-routability > > procedure. Appropriate enhancements could increase the > independence > > from the home agent and thus enable robust Route Optimization even > in > > the absence of the home agent. > > Regards, > > - Georg > > ------------------------------------------------------------------------ > > > *From:*Laganier, Julien [mailto:julienl@qualcomm.com] *Sent:* > Saturday, January 22, 2011 1:47 AM *To:* Hampel, K Georg (K Georg); > mext@ietf.org *Cc:* Klein, Thierry E (Thierry) *Subject:* RE: > Support of route optimization in *absence* of HA > > Georg, > > Regarding #1 I haven=92t decided yet I would like the group to discuss > more. The authorization of the MN to use a given HA could be asserted > in a couple of different ways, including but not limited to, a) the > HA only allows creation of initial binding for on-(home)-link MN, b) > the HA only allows creation of initial bindings for on-site MNs, > i.e., CoA in a provider prefix block, and c) the HA has access to a > list of CGA public keys that are authorized to create bindings. > > Regarding #2, if I am not mistaken, at least the 3GPP Evolved Packet > System mandates stateless address autoconfiguration for global > addresses. Only the link-local address is generated from the IID > sent by the GW. > > Best, > > --julien > > *From:*Hampel, K Georg (K Georg) > [mailto:georg.hampel@alcatel-lucent.com] *Sent:* Friday, January 21, > 2011 11:22 AM *To:* Laganier, Julien; Hampel, K Georg (K Georg); > mext@ietf.org *Cc:* Klein, Thierry E (Thierry) *Subject:* RE: > Support of route optimization in *absence* of HA > > Julien, > > Thanks for the info. I like your proposal. CGA provides > cryptographic security without need for trust-relationships, PKI, > pre-shared keys, etc. > > 1) When IPsec is replaced by CGA, MN only proves the authenticity of > its HoA to the HA. It does not authenticate itself in absolute > terms, i.e. via means of strong authentication as required by IPsec > or TLS. How would the HA know that this MN is authorized to use the > HA=92s services? > > 2) Do we have any idea to what extend stateless addressing is > =93supported=94? Does (or will) 3GPP allow stateless addressing? > > -Georg > > ------------------------------------------------------------------------ > > > *From:*Laganier, Julien [mailto:julienl@qualcomm.com] *Sent:* > Friday, January 21, 2011 1:06 PM *To:* Hampel, K Georg (K Georg); > mext@ietf.org *Cc:* Klein, Thierry E (Thierry) *Subject:* RE: > Support of route optimization in *absence* of HA > > Georg, > > Thanks for clarifying, this is what I thought. FWIW, I=92ve tried to > extend the RFC 4866 to secure bindings between the MN and the HA in > http://tools.ietf.org/html/draft-laganier-mext-cga-01 > > --julien > > *From:*Hampel, K Georg (K Georg) > [mailto:georg.hampel@alcatel-lucent.com] *Sent:* Thursday, January > 20, 2011 5:25 PM *To:* Laganier, Julien; mext@ietf.org *Cc:* Klein, > Thierry E (Thierry) *Subject:* RE: Support of route optimization in > *absence* of HA > > Julien, > > The intentions of Homeless MIPv6 are similar to those of our > proposal. > > In contrast to Homeless MIPv6, our proposal requires only minimal > upgrades to the present standard and implementation. (Homeless MIPv6 > requires changes to the TCP/UDP and requires AH, for instance). > > Here=92s the core idea of HA-free R/O: > > 1)When starting a session, the MN self-declares its current IP > address as the =93HoA=94 for this session. This automatically means that > it resides in its =93home network=94 and can conduct the home test > directly with CN, i.e. no home registration required. > > 2)All further BU/BA signaling is done directly with CN according to > RFC 4866. > > 3)All further signaling with HA is simply omitted. > > Our proposal builds on =93enhanced route optimization=94 (RFC 4866), > which provides a nice security solution for R/O and creates the > ground for HA-free operation. > > Little changes are required: e.g. MN must be able to deregister its > HoA at CN, etc. > > Regards, > > Georg > > ------------------------------------------------------------------------ > > > *From:*Laganier, Julien [mailto:julienl@qualcomm.com] *Sent:* > Thursday, January 20, 2011 4:27 PM *To:* Hampel, K Georg (K Georg); > mext@ietf.org *Cc:* Klein, Thierry E (Thierry) *Subject:* RE: > Support of route optimization in *absence* of HA > > Georg, > > Is it correct that functionally your proposal is similar to Homeless > Mobile IPv6: > > http://tools.ietf.org/html/draft-nikander-mobileip-homelessv6-01 > > Best, > > --julien > > *From:*mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] *On > Behalf Of *Hampel, K Georg (K Georg) *Sent:* Thursday, January 20, > 2011 12:07 PM *To:* mext@ietf.org *Cc:* Hampel, K Georg (K Georg); > Klein, Thierry E (Thierry) *Subject:* [MEXT] Support of route > optimization in *absence* of HA > > All, > > We would like to add a proposal to MEXT that permits the mobile to > engage into route-optimization in *absence* of a home agent. > > Such a feature adds robustness to route optimization in case the HA > is temporarily unavailable. Under some circumstances, route > optimization *without* HA may be beneficial for performance reasons. > Our proposal requires =93enhanced route optimization for Mobile IPv6=94 > (RFC 4866) as pre-requisite. > > We would like to obtain some feedback from the MEXT community via > this mailing list before we submit the proposal as a draft to the > workgroup. For this purpose, we have enclosed a high-level outline > below. Thanks. > > Regards, > > Georg Hampel > > Networking & Networks Domain > > BellLaboratories > > Alcatel-Lucent > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > Proposal: Support of Route-Optimization in Absence of Home Agent > > ABSTRACT: > > The proposal allows the mobile to engage into route optimization > (R/O) in *absence* of a HA. This feature increases robustness when > the HA becomes temporarily unavailable. Under some circumstances, > R/O *without* HA may be beneficial for performance reasons. This > proposal requires =93enhanced route optimization for Mobile IPv6=94 (RFC > 4866) as pre-requisite. > > MOTIVATION: > > In route optimization (R/O), traffic packets are directly exchanged > between hosts without passing the HA. The mobile, however, still has > to interact with the HA. The HA provides (1) location service, (2) a > fallback path in case the direct path breaks, (3) a fallback in case > the correspondent does not support the protocol and (4) security > support for R/O-related signaling (i.e. home test). These functions > come at the following cost: > > =B7Handovers may fail when the link to the HA or the HA itself are > down or congested. Mobility is not supported, when the mobile does > not have a HA. > > =B7When the mobile starts a session outside of its home network, it > must use a HoA pertaining to its home network even if it engages > into R/O. This requirement adds air-interface overhead due to > mobility headers and processing overhead on the mobile. This upfront > cost incurs even if the mobile does not move during the session. > > =B7Signaling handshakes have to be conducted between mobile and HA at > every mobility event. > > Currently, the Mobile IPv6 standard family forces the mobile to bear > these disadvantages in R/O even if the HA functions are not needed. > This specifically applies to scenarios where: > > =B7Traffic is based on mobile-initiated requests to public servers > (majority of present mobile internet traffic). The HA=92s location > service is not needed for such traffic. Location service may also be > provided by other means such as Dynamic DNS or on application layer > (e.g. SIP registrar). > > =B7The fallback path through the HA has little value when it shares > the weakest link with the direct path. Since the weakest link is > typically the wireless link, this situation applies to all scenarios > where only one air interface is available (this is the typical case > rather than the exception). > > =B7The mobile may know about the correspondent=92s Mobile-IPv6 support > from prior sessions or through means external to the standard. > > =B7The mobile applies the CGA-based procedure of RFC 4866, which makes > the HA=92s security support for R/O unnecessary. This applies to all > cases where stateless addressing is permitted. > > To increase the flexibility and robustness of route-optimized Mobile > IPv6, we propose to make the HA an *optional* rather than a > *mandatory* feature, i.e. to permit operation without HA. This > proposal requires some additional extensions to the present > standard. > > HIGH-LEVEL OUTLINE > > The extensions build on Enhanced Route Optimization for Mobile IPv6 > (RFC 4866) to guarantee sufficient signaling security. With the > absence of a HA, mobility support in R/O can be provided in the > following manner: > > =B7The mobile starts the traffic session from any of its currently > supported IP addresses. The selected IP address automatically takes > the function of the HoA for this session. This has the advantage > that conventional transport is used as long as the mobile does not > move, i.e. mobility headers and CoA-vs-HoA mapping is not needed. The > HoA must have been generated via CGA in compliance with RFC 4866. > > =B7The mobile must conduct a =93home-test=94 from this HoA in compliance > with RFC 4866. It may conduct the home-test prior to session > establishment, e.g. to find out if the correspondent supports the > standard. > > =B7All binding update handshakes are conducted on the direct path > according to RFC 4866. > > =B7Since sessions are always started from a currently supported IP > address, temporally overlapping sessions may use different HoAs. A > multi-homed mobile may also decide to start sessions from different > simultaneously supported IP addresses. There is no principle problem > here. > > =B7Opposed to RFC 4866, the mobile need not perform the CoA > registration with the HA. > > =B7The mobile must be able to deregister the HoA at the correspondent > in case the HoA is not supported anymore. This ensures that the > correspondent does not send packets to the HoA. After deregistration > of the HoA, the HoA is still used by higher protocol layers of > ongoing sessions. It must still be included in the mobility headers > for these sessions. > > =B7When the mobile has HA support and the HA becomes temporarily > unavailable, the mobile simply continues R/O without HA as outlined > in the prior points. > > =B7The mobile can publish its IP address in any location service. This > allows other hosts to initiate sessions with the mobile. These > sessions enjoy route-optimized mobility support only if the > published IP address was generated via CGA in compliance with RFC > 4866. > > OPEN ISSUES > > These extensions have to be made compliant with RFC 5648 (multiple > CoA registration), RFC 3963 (NEMO) and others. More discussions are > necessary. > > > > _______________________________________________ MEXT mailing list > MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From domagoj.premec@gmail.com Wed Jan 26 06:22:34 2011 Return-Path: <domagoj.premec@gmail.com> X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A6AC3A69CD for <mext@core3.amsl.com>; Wed, 26 Jan 2011 06:22:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yynEsfolZBNd for <mext@core3.amsl.com>; Wed, 26 Jan 2011 06:22:33 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 2B2BB3A69CC for <mext@ietf.org>; Wed, 26 Jan 2011 06:22:33 -0800 (PST) Received: by iwn40 with SMTP id 40so1005285iwn.31 for <mext@ietf.org>; Wed, 26 Jan 2011 06:25:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=VegHwFURPcH/ShD7ZTsMKS9YpoP0fX5pWA2z1RJkEXw=; b=lrFkmeVaoqwvwzBp/VrsGd578dt7fHNK9do76z07ZrrsJ/JBvkJsE8QXtdRLmq12lQ lBUSuWarPHcFNlhu3BZ0c9Qy+YGrR3A7tCnljYjyUv+QrwXsw5L/D8RRpbCVViE7FPuC oHMdUHH8w6TNsZ3//jDL5oKCkmiA40XjYreMg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=buuWTt5+SQjrodFSQe+6myWe9VdSW222Z7LGT1X1UDdlrg7ELw0nm+oOfT4o+D8mJo ytZqOFVIdUB6CX1x4ZHEK9gamO2BUGJ3ZSxeYaWOthjNbki7Gl+Z1jlxszxYjvKWOu69 cK9dg+BewONqPllvEb8H3xbN4S14j/+YPW5yo= MIME-Version: 1.0 Received: by 10.42.172.130 with SMTP id n2mr520318icz.276.1296051933677; Wed, 26 Jan 2011 06:25:33 -0800 (PST) Received: by 10.42.225.9 with HTTP; Wed, 26 Jan 2011 06:25:33 -0800 (PST) Date: Wed, 26 Jan 2011 15:25:33 +0100 Message-ID: <AANLkTikGBOTOopf5g0SVvSe1-f1fBK38CN+mSnPdp+8D@mail.gmail.com> From: Domagoj Premec <domagoj.premec@gmail.com> To: mext@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [MEXT] Call for WG adoption of I-D: draft-korhonen-mext-mip6-altsec X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG <mext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/mext> List-Post: <mailto:mext@ietf.org> List-Help: <mailto:mext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 26 Jan 2011 14:22:34 -0000 I support this draft moving forward and becoming a WG document. IMO the current IPSec based security for MIP6 does have its drawbacks and this draft offers an interesting alternative. I was able to play around a bit with a MIP6 client implementing this draft, and it worked flawlessly and to set it up was a breeze. Domagoj > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > Behalf Of marcelo bagnulo braun > Sent: Monday, January 24, 2011 8:34 PM > To: mext > Subject: [MEXT] Call for WG adoption of I-D: > draft-korhonen-mext-mip6-altsec > > The ID has had 3 reviews as we require. > So, we are now ready to ask the WG if they think we should adopt the > document. > > Please express your opinion before monday 31st jan. > > Reviews can be found: > > The I-D: draft-korhonen-mext-mip6-altsec-06 has been reviewed by: > > 1. Jan Zorz > http://www.ietf.org/mail-archive/web/mext/current/msg04489.html > > 2. Domagoz Premec > http://www.ietf.org/mail-archive/web/mext/current/msg04457.html > > 3. Ryuji Wakikawa > http://www.ietf.org/mail-archive/web/mext/current/msg04470.html > > > > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > From georg.hampel@alcatel-lucent.com Wed Jan 26 11:01:01 2011 Return-Path: <georg.hampel@alcatel-lucent.com> X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 469DC3A67AC for <mext@core3.amsl.com>; Wed, 26 Jan 2011 11:01:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Un+DDYwe8FqD for <mext@core3.amsl.com>; Wed, 26 Jan 2011 11:00:59 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by core3.amsl.com (Postfix) with ESMTP id 2C81D3A67A6 for <mext@ietf.org>; Wed, 26 Jan 2011 11:00:58 -0800 (PST) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id p0QJ3tEB021585 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 26 Jan 2011 13:03:56 -0600 (CST) Received: from USNAVSXCHHUB02.ndc.alcatel-lucent.com (usnavsxchhub02.ndc.alcatel-lucent.com [135.3.39.111]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p0QJ3hDP000364 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 26 Jan 2011 13:03:55 -0600 Received: from USNAVSXCHMBSA2.ndc.alcatel-lucent.com ([135.3.39.127]) by USNAVSXCHHUB02.ndc.alcatel-lucent.com ([135.3.39.111]) with mapi; Wed, 26 Jan 2011 13:03:48 -0600 From: "Hampel, K Georg (K Georg)" <georg.hampel@alcatel-lucent.com> To: =?iso-8859-1?Q?M=E4kel=E4_Antti?= <antti.makela@aalto.fi>, Alexandru Petrescu <alexandru.petrescu@gmail.com>, "mext@ietf.org" <mext@ietf.org> Date: Wed, 26 Jan 2011 13:03:46 -0600 Thread-Topic: [MEXT] Support of route optimization in *absence* of HA Thread-Index: AQHLvLj8UEf1urDUyUWHHSacIaQ4WJPjE1YFgACCiCA= Message-ID: <154773479ED2314980CB638A48FC4434833BA59E@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> References: <154773479ED2314980CB638A48FC44348334CE4F@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <98A16B2D00B5724F81E80EF1927A0297036BB6@nasanexd01e.na.qualcomm.com> <154773479ED2314980CB638A48FC44348334CFA1@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <98A16B2D00B5724F81E80EF1927A029703A7F6@nasanexd01e.na.qualcomm.com> <154773479ED2314980CB638A48FC44348334D271@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <98A16B2D00B5724F81E80EF1927A029703CA27@nasanexd01e.na.qualcomm.com> <154773479ED2314980CB638A48FC4434833B9F67@USNAVSXCHMBSA2.ndc.alcatel-lucent.com>, <31821_1295978112_4D3F0E80_31821_2069_1_4D3F0E74.5020403@gmail.com> <64FACAB831EEEB418F27A18FE09095243CF932C6@EXMDB08.org.aalto.fi> In-Reply-To: <64FACAB831EEEB418F27A18FE09095243CF932C6@EXMDB08.org.aalto.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Subject: Re: [MEXT] Support of route optimization in *absence* of HA X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG <mext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/mext> List-Post: <mailto:mext@ietf.org> List-Help: <mailto:mext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 26 Jan 2011 19:01:01 -0000 Hi Antti, It would make sense to quantify your concerns about persistent connections = that "borrow" IP addresses from foreign networks for extended time. I don't= see a problem if the "HoA" is only used by upper layers, i.e. when the MN = has already moved to another netowrk. DHCPv6 lease expiry may be a problem = when the MN stays in the foreign network for an extended period of time and= the lease cannot be renewed (Stateless address autoconfiguration should no= t encounter this problem ?!.:) HA-free RO has other limits: - Simultaneous movment of both end points cannot be supported in break-befo= re-make manner. - Applications that cache and reuse IP addreses after some time run into tr= ouble if mobility events have occurred in between. - Mobile servers require support of dynamic location service. I think HA-free RO should be considered an option which provides net benefi= ts for a large fraction of traffic. It does not have to cover *all* situati= ons. I think it is important to identify potential vulnerabilities. In most= cases, however, the worst that can happen is that the conenction breaks. - Georg -----Original Message----- From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of M= =E4kel=E4 Antti Sent: Wednesday, January 26, 2011 6:22 AM To: Alexandru Petrescu; mext@ietf.org Subject: Re: [MEXT] Support of route optimization in *absence* of HA Hi, HA-less RO sounds like a very interesting effort. The resemblances to ad-= hoc routing are quite large though. From how I understood the draft, the us= e case and primary scenario is the situation where the mobile node has most= ly outbound traffic, and simply needs to make sure that sessions don't get = interrupted if the node moves. I agree that security should probably be made "modular" in the sense that= you are free to secure the RO with any way you choose, or even without any= security at all (in a trusted environment). In essence the current suggestion sounds like: Mobile Node chooses a "HoA" from one of the current interface addresses a= nd acts as it's in "home network" Starts communicating with CN If node moves, tell the CN via RO procedure that me, previously at home, = now have a CoA that corresponds to my HoA Any new sessions should use the new network's address as "HoA", and if th= e session to the CN ends, the RO should be torn down as well. My primary concerns with this basic idea are related to persistent sessio= ns - some application connecting to the CN and keeping the same connection,= so the MN can never relinquish the HoA. This leads to the philosophical is= sue about if you are a mobile node and using such "ad-hoc" HoAs that you ha= ve picked up on the way, do you have the permission to make such address mo= bile (take it out of the network)? In an environment with HA, the HA gives you explicit permission that yes,= you can use this address, from my network, owned by me, to communicate wit= h rest of the world. Without HA, considering whatever network you happen to be in when first c= ommunicating to a CN your "home network" - should the MN be allowed to move= the HoA away? For how long? Until DHCPv6 lease expires? Until RA timer expires? When? -- - Antti M=E4kel=E4 | Researcher - - Department of communications and networking - - Aalto University - ________________________________________ From: mext-bounces@ietf.org [mext-bounces@ietf.org] on behalf of Alexandru = Petrescu [alexandru.petrescu@gmail.com] Sent: Tuesday, January 25, 2011 19:55 To: mext@ietf.org Subject: Re: [MEXT] Support of route optimization in *absence* of HA Thanks for listing these 3 documents. For what it's worth... I think it would be good to decouple the security effort from the HA-less part of the effort. I would thus go further with the proposal to operate on a more general level. Do you have anything against a basic RO HA-less which is security-less as well? If against, then it would make sense to talk _Secure_ HA-less RO RR. If for, then it would make sense to cite http://tools.ietf.org/html/draft-petrescu-autoconf-ra-based-routing-00 and MNPP draft along the 3 documents you cited. I think a basic RO HA-less which is independent of the security mechanism could become a place for adding more security later. For example: add a widely deployed certificate-based https security which secures a link layer (and not CGA, not Mobile IP RR tests). I think that if one tries to further develop existing Mobile IP security mechanisms (CGA, IKE, RR tests) then the goal should be stated in the title, call the effort a security effort, and not simply RO, nor simply RR. For example: return routability tests (called RR in Mobile IP only) exists in other protocols as well (TCP) yet they're not as highly secure as in Mobile IPv6 (nonces, keys). In this sense, in Mobile IP, RR is actually a security effort. RO of Mobile IP does not exist without RR, hence RO is also a security effort. However, it is possible to achieve optimal paths ("route optimization"), without using security. For example, most paths in the Internet are highly optimal in terms of path length, yet very few of them are established securely. I think Mobile IP needs means to offer optimal paths CN-MH (move HA out of the path). However, the effort of offering these paths is not necessarily a security effort. Alex Le 25/01/2011 16:44, Hampel, K Georg (K Georg) a =E9crit : > All, > > Based on feedback and further thoughts, I propose to permit HA-free > operation on a more general level, i.e. for ALL R/O-solutions that > permit return-routability procedure WITHOUT participation of the HA. > Among those are currently: > > - RFC 4866: Enhanced R/O for MIPv6 > > - RFC 4449: Securing MIPv6 R/O using static shared key > > - draft-ebalard-mext-ipsec-ro-01: Mobile IPv6 IPsec Route > Optimization (IRO) > > Note that HA-free R/O was already anticipated by RFC 4651 (A > Taxonomy and Analysis of Enhancements to Mobile IPv6 Route > Optimization). I think it would add substantial value to MIPv6. RFC > 4651 says: > > > > 2.4. Robustness Enhancements > > > > Route Optimization could conceptually enable continued > communications > > during periods of temporary home-agent unavailability. The > protocol > > defined in RFC 3775 does not achieve this independence, however, as > > the home agent plays an active role in the return-routability > > procedure. Appropriate enhancements could increase the > independence > > from the home agent and thus enable robust Route Optimization even > in > > the absence of the home agent. > > Regards, > > - Georg > > ------------------------------------------------------------------------ > > > *From:*Laganier, Julien [mailto:julienl@qualcomm.com] *Sent:* > Saturday, January 22, 2011 1:47 AM *To:* Hampel, K Georg (K Georg); > mext@ietf.org *Cc:* Klein, Thierry E (Thierry) *Subject:* RE: > Support of route optimization in *absence* of HA > > Georg, > > Regarding #1 I haven't decided yet I would like the group to discuss > more. The authorization of the MN to use a given HA could be asserted > in a couple of different ways, including but not limited to, a) the > HA only allows creation of initial binding for on-(home)-link MN, b) > the HA only allows creation of initial bindings for on-site MNs, > i.e., CoA in a provider prefix block, and c) the HA has access to a > list of CGA public keys that are authorized to create bindings. > > Regarding #2, if I am not mistaken, at least the 3GPP Evolved Packet > System mandates stateless address autoconfiguration for global > addresses. Only the link-local address is generated from the IID > sent by the GW. > > Best, > > --julien > > *From:*Hampel, K Georg (K Georg) > [mailto:georg.hampel@alcatel-lucent.com] *Sent:* Friday, January 21, > 2011 11:22 AM *To:* Laganier, Julien; Hampel, K Georg (K Georg); > mext@ietf.org *Cc:* Klein, Thierry E (Thierry) *Subject:* RE: > Support of route optimization in *absence* of HA > > Julien, > > Thanks for the info. I like your proposal. CGA provides > cryptographic security without need for trust-relationships, PKI, > pre-shared keys, etc. > > 1) When IPsec is replaced by CGA, MN only proves the authenticity of > its HoA to the HA. It does not authenticate itself in absolute > terms, i.e. via means of strong authentication as required by IPsec > or TLS. How would the HA know that this MN is authorized to use the > HA's services? > > 2) Do we have any idea to what extend stateless addressing is > "supported"? Does (or will) 3GPP allow stateless addressing? > > -Georg > > ------------------------------------------------------------------------ > > > *From:*Laganier, Julien [mailto:julienl@qualcomm.com] *Sent:* > Friday, January 21, 2011 1:06 PM *To:* Hampel, K Georg (K Georg); > mext@ietf.org *Cc:* Klein, Thierry E (Thierry) *Subject:* RE: > Support of route optimization in *absence* of HA > > Georg, > > Thanks for clarifying, this is what I thought. FWIW, I've tried to > extend the RFC 4866 to secure bindings between the MN and the HA in > http://tools.ietf.org/html/draft-laganier-mext-cga-01 > > --julien > > *From:*Hampel, K Georg (K Georg) > [mailto:georg.hampel@alcatel-lucent.com] *Sent:* Thursday, January > 20, 2011 5:25 PM *To:* Laganier, Julien; mext@ietf.org *Cc:* Klein, > Thierry E (Thierry) *Subject:* RE: Support of route optimization in > *absence* of HA > > Julien, > > The intentions of Homeless MIPv6 are similar to those of our > proposal. > > In contrast to Homeless MIPv6, our proposal requires only minimal > upgrades to the present standard and implementation. (Homeless MIPv6 > requires changes to the TCP/UDP and requires AH, for instance). > > Here's the core idea of HA-free R/O: > > 1)When starting a session, the MN self-declares its current IP > address as the "HoA" for this session. This automatically means that > it resides in its "home network" and can conduct the home test > directly with CN, i.e. no home registration required. > > 2)All further BU/BA signaling is done directly with CN according to > RFC 4866. > > 3)All further signaling with HA is simply omitted. > > Our proposal builds on "enhanced route optimization" (RFC 4866), > which provides a nice security solution for R/O and creates the > ground for HA-free operation. > > Little changes are required: e.g. MN must be able to deregister its > HoA at CN, etc. > > Regards, > > Georg > > ------------------------------------------------------------------------ > > > *From:*Laganier, Julien [mailto:julienl@qualcomm.com] *Sent:* > Thursday, January 20, 2011 4:27 PM *To:* Hampel, K Georg (K Georg); > mext@ietf.org *Cc:* Klein, Thierry E (Thierry) *Subject:* RE: > Support of route optimization in *absence* of HA > > Georg, > > Is it correct that functionally your proposal is similar to Homeless > Mobile IPv6: > > http://tools.ietf.org/html/draft-nikander-mobileip-homelessv6-01 > > Best, > > --julien > > *From:*mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] *On > Behalf Of *Hampel, K Georg (K Georg) *Sent:* Thursday, January 20, > 2011 12:07 PM *To:* mext@ietf.org *Cc:* Hampel, K Georg (K Georg); > Klein, Thierry E (Thierry) *Subject:* [MEXT] Support of route > optimization in *absence* of HA > > All, > > We would like to add a proposal to MEXT that permits the mobile to > engage into route-optimization in *absence* of a home agent. > > Such a feature adds robustness to route optimization in case the HA > is temporarily unavailable. Under some circumstances, route > optimization *without* HA may be beneficial for performance reasons. > Our proposal requires "enhanced route optimization for Mobile IPv6" > (RFC 4866) as pre-requisite. > > We would like to obtain some feedback from the MEXT community via > this mailing list before we submit the proposal as a draft to the > workgroup. For this purpose, we have enclosed a high-level outline > below. Thanks. > > Regards, > > Georg Hampel > > Networking & Networks Domain > > BellLaboratories > > Alcatel-Lucent > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > Proposal: Support of Route-Optimization in Absence of Home Agent > > ABSTRACT: > > The proposal allows the mobile to engage into route optimization > (R/O) in *absence* of a HA. This feature increases robustness when > the HA becomes temporarily unavailable. Under some circumstances, > R/O *without* HA may be beneficial for performance reasons. This > proposal requires "enhanced route optimization for Mobile IPv6" (RFC > 4866) as pre-requisite. > > MOTIVATION: > > In route optimization (R/O), traffic packets are directly exchanged > between hosts without passing the HA. The mobile, however, still has > to interact with the HA. The HA provides (1) location service, (2) a > fallback path in case the direct path breaks, (3) a fallback in case > the correspondent does not support the protocol and (4) security > support for R/O-related signaling (i.e. home test). These functions > come at the following cost: > > =B7Handovers may fail when the link to the HA or the HA itself are > down or congested. Mobility is not supported, when the mobile does > not have a HA. > > =B7When the mobile starts a session outside of its home network, it > must use a HoA pertaining to its home network even if it engages > into R/O. This requirement adds air-interface overhead due to > mobility headers and processing overhead on the mobile. This upfront > cost incurs even if the mobile does not move during the session. > > =B7Signaling handshakes have to be conducted between mobile and HA at > every mobility event. > > Currently, the Mobile IPv6 standard family forces the mobile to bear > these disadvantages in R/O even if the HA functions are not needed. > This specifically applies to scenarios where: > > =B7Traffic is based on mobile-initiated requests to public servers > (majority of present mobile internet traffic). The HA's location > service is not needed for such traffic. Location service may also be > provided by other means such as Dynamic DNS or on application layer > (e.g. SIP registrar). > > =B7The fallback path through the HA has little value when it shares > the weakest link with the direct path. Since the weakest link is > typically the wireless link, this situation applies to all scenarios > where only one air interface is available (this is the typical case > rather than the exception). > > =B7The mobile may know about the correspondent's Mobile-IPv6 support > from prior sessions or through means external to the standard. > > =B7The mobile applies the CGA-based procedure of RFC 4866, which makes > the HA's security support for R/O unnecessary. This applies to all > cases where stateless addressing is permitted. > > To increase the flexibility and robustness of route-optimized Mobile > IPv6, we propose to make the HA an *optional* rather than a > *mandatory* feature, i.e. to permit operation without HA. This > proposal requires some additional extensions to the present > standard. > > HIGH-LEVEL OUTLINE > > The extensions build on Enhanced Route Optimization for Mobile IPv6 > (RFC 4866) to guarantee sufficient signaling security. With the > absence of a HA, mobility support in R/O can be provided in the > following manner: > > =B7The mobile starts the traffic session from any of its currently > supported IP addresses. The selected IP address automatically takes > the function of the HoA for this session. This has the advantage > that conventional transport is used as long as the mobile does not > move, i.e. mobility headers and CoA-vs-HoA mapping is not needed. The > HoA must have been generated via CGA in compliance with RFC 4866. > > =B7The mobile must conduct a "home-test" from this HoA in compliance > with RFC 4866. It may conduct the home-test prior to session > establishment, e.g. to find out if the correspondent supports the > standard. > > =B7All binding update handshakes are conducted on the direct path > according to RFC 4866. > > =B7Since sessions are always started from a currently supported IP > address, temporally overlapping sessions may use different HoAs. A > multi-homed mobile may also decide to start sessions from different > simultaneously supported IP addresses. There is no principle problem > here. > > =B7Opposed to RFC 4866, the mobile need not perform the CoA > registration with the HA. > > =B7The mobile must be able to deregister the HoA at the correspondent > in case the HoA is not supported anymore. This ensures that the > correspondent does not send packets to the HoA. After deregistration > of the HoA, the HoA is still used by higher protocol layers of > ongoing sessions. It must still be included in the mobility headers > for these sessions. > > =B7When the mobile has HA support and the HA becomes temporarily > unavailable, the mobile simply continues R/O without HA as outlined > in the prior points. > > =B7The mobile can publish its IP address in any location service. This > allows other hosts to initiate sessions with the mobile. These > sessions enjoy route-optimized mobility support only if the > published IP address was generated via CGA in compliance with RFC > 4866. > > OPEN ISSUES > > These extensions have to be made compliant with RFC 5648 (multiple > CoA registration), RFC 3963 (NEMO) and others. More discussions are > necessary. > > > > _______________________________________________ MEXT mailing list > MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From Fred.L.Templin@boeing.com Wed Jan 26 13:24:00 2011 Return-Path: <Fred.L.Templin@boeing.com> X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A13A3A69D9 for <mext@core3.amsl.com>; Wed, 26 Jan 2011 13:24:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.469 X-Spam-Level: X-Spam-Status: No, score=-6.469 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pDjIzOkSx2Rl for <mext@core3.amsl.com>; Wed, 26 Jan 2011 13:23:59 -0800 (PST) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by core3.amsl.com (Postfix) with ESMTP id 621653A69DC for <mext@ietf.org>; Wed, 26 Jan 2011 13:23:59 -0800 (PST) Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by stl-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p0QLQqs6028458 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <mext@ietf.org>; Wed, 26 Jan 2011 15:26:53 -0600 (CST) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id p0QLQqho012111 for <mext@ietf.org>; Wed, 26 Jan 2011 13:26:52 -0800 (PST) Received: from XCH-NWHT-09.nw.nos.boeing.com (xch-nwht-09.nw.nos.boeing.com [130.247.25.115]) by slb-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p0QLQphN012072 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK) for <mext@ietf.org>; Wed, 26 Jan 2011 13:26:52 -0800 (PST) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-09.nw.nos.boeing.com ([130.247.25.115]) with mapi; Wed, 26 Jan 2011 13:26:51 -0800 From: "Templin, Fred L" <Fred.L.Templin@boeing.com> To: "mext@ietf.org" <mext@ietf.org> Date: Wed, 26 Jan 2011 13:26:50 -0800 Thread-Topic: IRON - a new approach to mobility management Thread-Index: Acu9ZObUeEtp4wpfT9m3W4BGslqdFwAIrYJQ Message-ID: <E1829B60731D1740BB7A0626B4FAF0A65C682836E4@XCH-NW-01V.nw.nos.boeing.com> References: <AANLkTikGBOTOopf5g0SVvSe1-f1fBK38CN+mSnPdp+8D@mail.gmail.com> In-Reply-To: <AANLkTikGBOTOopf5g0SVvSe1-f1fBK38CN+mSnPdp+8D@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [MEXT] IRON - a new approach to mobility management X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG <mext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/mext> List-Post: <mailto:mext@ietf.org> List-Help: <mailto:mext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 26 Jan 2011 21:24:00 -0000 Hello, I would like to introduce a new approach to mobility management, which is an in-built feature of a new routing and addressing system known as the Internet Routing Overlay Network (IRON): http://www.rfc-editor.org/internet-drafts/draft-templin-iron-17.txt IRON is a product of the IRTF Routing Research Group (RRG), which was chartered to provide recommendations on addressing the Internet routing scaling issue. While the IRON development effort focused primarily on routing scaling, it soon became clear that mobility management was also naturally afforded by the base architecture with no need for adjunct mechanisms. Also, although this fully-integrated proposal is new many of the concepts were motivated by earlier works. The document therefore cites related initiatives which explored similar concepts. The IRON mobility management approach combines the best aspects of both proactive and on-demand route discovery. IRON Clients (which may include mobile end systems and mobile routers) discover topologically-close IRON Serving routers (i.e., "Servers") and create a connection with one of the Servers for the purpose of maintaining=20 bidirectional tunnel neighbor state. The Client then registers one or more of its interfaces with the Server so that the Server has handles for sending return traffic to the Client. Since the Server can observe the public-side address(es) of the Client without the Client needing to discover them itself, the system therefore also naturally supports a simplified form of NAT traversal.=20 When a Client connects to the Server, the Server sends a "link up" indication via a dynamic routing update that is propagated to a core set of Relay routers (i.e., "Relays"). In practice, there will be O(10's) of Relays while there may be several orders of magnitude more Servers that are topologically distributed throughout the Internet. Only the Relays need maintain a full topology in their routing tables; Servers need only maintain routing table entries for their current set of connected Clients. When a Client 'A' connected to Server 'Y' has a packet to send to a new correspondent Client 'B' connected to Server 'Z', 'A' first tunnels the packet to 'Y' as its default router in the overlay network. Since 'Y' has only partial topology information, it then tunnels the packet to a Relay 'R'. Since 'R' has full topology knowledge, it then tunnels the packet to 'Z' which in turn tunnels the packet to 'B'. At the same time, 'Z' also returns a Redirect message to inform 'Y' that 'Z' is a better next hop in the overlay network to reach 'B'. If 'Y' is configured to forward Redirects to its Clients, it then forwards the Redirect to 'A' which then populates its routing tables with a more- specific route. Otherwise, 'Y' uses the Redirect to update its own routing tables. Hence, route optimization is naturally supported. When 'A' changes its ISP points of attachement (i.e., when 'A' moves), it need not explicitly inform 'Y' of the changes as long as it wishes to retain 'Y' as its Server, since 'Y' will naturally discover any changes in 'A''s address(es) via the source addresses of 'A''s packets. 'A' also need not inform any of its recent correspondents about the changes, since the correspondents can still reach 'A' via 'Y'. Hence, localized mobility events are communicated implicitly and immediately with no need for binding updates. When 'A' moves far away from 'Y', it can leisurely discover a new nearby Server 'W'. It can then connect to 'W' and disconnect from 'Y' which will cause dynamic routing between the overlay network Relays to naturally update 'A''s Client-to-Server bindings. Hence, routing stretch is managed without need for delay-sensitive actions. Finally, the base system does not require Client-to-Client binding updates. For example, if Client 'C' has a routing table for 'A' with next-hop 'Y', but 'A' has moved to a new Server 'W', 'C' will receive Redirect messages from 'Y' informing it that 'A' is now associated with 'W'. Hence, 'A' need not keep track of recent correspondents, since any correspondents will naturally be redirected to 'A's new location without risk of packet loss. (Again, this is a coarse-grained mobility consideration, since 'A' will typically not change to a new Server unless it moves some significant distance, e.g., 1000 miles). Comments and questions welcome, Fred fred.l.etmplin@boeing.com= From julienl@qualcomm.com Wed Jan 26 15:16:35 2011 Return-Path: <julienl@qualcomm.com> X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B11463A68AF for <mext@core3.amsl.com>; Wed, 26 Jan 2011 15:16:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.373 X-Spam-Level: X-Spam-Status: No, score=-106.373 tagged_above=-999 required=5 tests=[AWL=0.226, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sNgi2X5TzhK9 for <mext@core3.amsl.com>; Wed, 26 Jan 2011 15:16:34 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 4B5E63A6A04 for <mext@ietf.org>; Wed, 26 Jan 2011 15:16:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1296083976; x=1327619976; h=from:to:cc:subject:thread-topic:thread-index:date: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: x-originating-ip:content-type:content-transfer-encoding: mime-version; z=From:=20"Laganier,=20Julien"=20<julienl@qualcomm.com> |To:=20jouni=20korhonen=20<jouni.nospam@gmail.com>|CC:=20 "mext@ietf.org"=20<mext@ietf.org>,=20"jan@go6.si"=20<jan@ go6.si>,=0D=0A=09"Basavaraj.Patil@nokia.com"=20<Basavaraj .Patil@nokia.com>|Subject:=20RE:=20[MEXT]=20Call=20for=20 WG=20adoption=20of=20I-D:=0D=0A=09draft-korhonen-mext-mip 6-altsec|Thread-Topic:=20[MEXT]=20Call=20for=20WG=20adopt ion=20of=20I-D:=0D=0A=09draft-korhonen-mext-mip6-altsec |Thread-Index:=20AQHLvS5ioJLiiK5cIUOVOwObIMivn5Pj4vDw |Date:=20Wed,=2026=20Jan=202011=2023:19:35=20+0000 |Message-ID:=20<98A16B2D00B5724F81E80EF1927A029703EAD4@na sanexd01e.na.qualcomm.com>|References:=20<878vyarmku.fsf@ natisbad.org>=0D=0A=09<C963527A.D013%basavaraj.patil@noki a.com>=0D=0A=09<98A16B2D00B5724F81E80EF1927A029703E3FB@na sanexd01e.na.qualcomm.com>=0D=0A=20<06CCEF13-4E11-474D-A2 5E-C1425D5B520A@gmail.com>|In-Reply-To:=20<06CCEF13-4E11- 474D-A25E-C1425D5B520A@gmail.com>|Accept-Language:=20en-U S|Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|x-originating-ip:=20[172.30.39.5] |Content-Type:=20text/plain=3B=20charset=3D"us-ascii" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=1zXzTKTE4D8iZefeBUxKnImFEV9S7KzqTn/kR+9rcPo=; b=pzS3CuxsTpZBpO9Qhd98PQSM9JIahHQKKHYxxT6hiNtIMGsGJUYb2O2N igkIkkk5WGpZMweaj8hfkVVVlNw80fWj9OP38MfCjMzuc9mTl25xdaBUz moTqOkI39X2UeeOihCGR1T3oLxI5oAAtiXrRfnVaAcMG+LVV2Yier3HrT 8=; X-IronPort-AV: E=McAfee;i="5400,1158,6238"; a="72109431" Received: from ironmsg02-r.qualcomm.com ([172.30.46.16]) by wolverine01.qualcomm.com with ESMTP; 26 Jan 2011 15:19:35 -0800 X-IronPort-AV: E=Sophos;i="4.60,380,1291622400"; d="scan'208";a="112799694" Received: from nasanexhc08.na.qualcomm.com ([172.30.39.7]) by ironmsg02-R.qualcomm.com with ESMTP/TLS/AES128-SHA; 26 Jan 2011 15:19:35 -0800 Received: from NASANEXD01E.na.qualcomm.com ([fe80::6555:8c37:4ee3:efc4]) by nasanexhc08.na.qualcomm.com ([::1]) with mapi id 14.01.0218.012; Wed, 26 Jan 2011 15:19:35 -0800 From: "Laganier, Julien" <julienl@qualcomm.com> To: jouni korhonen <jouni.nospam@gmail.com> Thread-Topic: [MEXT] Call for WG adoption of I-D: draft-korhonen-mext-mip6-altsec Thread-Index: AQHLvS5ioJLiiK5cIUOVOwObIMivn5Pj4vDw Date: Wed, 26 Jan 2011 23:19:35 +0000 Message-ID: <98A16B2D00B5724F81E80EF1927A029703EAD4@nasanexd01e.na.qualcomm.com> References: <878vyarmku.fsf@natisbad.org> <C963527A.D013%basavaraj.patil@nokia.com> <98A16B2D00B5724F81E80EF1927A029703E3FB@nasanexd01e.na.qualcomm.com> <06CCEF13-4E11-474D-A25E-C1425D5B520A@gmail.com> In-Reply-To: <06CCEF13-4E11-474D-A25E-C1425D5B520A@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.30.39.5] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Basavaraj.Patil@nokia.com" <Basavaraj.Patil@nokia.com>, "jan@go6.si" <jan@go6.si>, "mext@ietf.org" <mext@ietf.org> Subject: Re: [MEXT] Call for WG adoption of I-D: draft-korhonen-mext-mip6-altsec X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG <mext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/mext> List-Post: <mailto:mext@ietf.org> List-Help: <mailto:mext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 26 Jan 2011 23:16:35 -0000 Hi Jouni, I understand you "follow the ESP format but feel no shame on changing it if= we see a reason to do so", but I am (shamelessly ;) wondering about the ac= tual reason to do so, as per one of the famous Architectural Principles of = the Internet documented in RFC 1958:=20 3.2 If there are several ways of doing the same thing, choose one. If a previous design, in the Internet context or elsewhere, has successfully solved the same problem, choose the same solution unless there is a good technical reason not to. Duplication of the same protocol functionality should be avoided as far as possible, without of course using this argument to reject improvements. Would you mind enlightening us? --julien jouni korhonen wrote: >=20 > Few things. The draft already states that "The Padding, Pad Length, > Next Header and ICV fields follow the rules of Section 2.4 to 2.8 of > [RFC4303] unless otherwise stated in this document." So, we follow > the ESP format but feel no shame on changing it if we see a reason > to do so. >=20 > The reason why we chose to do it like this was two fold: 1) some > ciphers etc when used would need ~equivalent encapsulation anyway.=20 > 2) if we had come up with our very own format the question on the > list would have been "why not using RFC4303 encapsulation format". > Actually.. the latter already happened offline. >=20 > - Jouni >=20 >=20 > On Jan 26, 2011, at 12:48 AM, Laganier, Julien wrote: >=20 > > Hi Raj, > > > >> Inline: > >> > >> On 1/24/11 3:58 PM, "ext Arnaud Ebalard" <arno@natisbad.org> wrote: > >> > >>> > >>> To me, what the draft describes is a patchwork based on MIPv6, ESP > and > >>> TLS. Instead of building on top of those protocols (read modularity > >> and > >>> interoperability), it reuses (hijacks) various blocks of associated > >>> standards in a non-modular way. For instance, one has to > reimplement > >> ESP > >>> in userspace to support the protocol. > >> > >> We are specifying an encapsulation method in the I-D. To say that > one > >> has to reimplement ESP in userspace is incorrect. > > > > The encapsulation format you have in the I-D is: > > > > 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 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | | > > : IPv4 or IPv6 header (src-addr=3DXa, dst-addr=3DYa) : > > | | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | | > > : UDP header (src-port=3DXp,dst-port=3DYp) : > > | | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- > --- > > |PType=3D8| SPI | > ^Int. > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |Cov- > > | Sequence Number | > |ered > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | - > --- > > | Payload Data* (variable) | | > ^ > > : : | > | > > | | > |Conf. > > + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |Cov- > > | | Padding (0-255 bytes) | > |ered* > > +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | > | > > | | Pad Length | Next Header | v > v > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- > --- > > | Integrity Check Value-ICV (variable) | > > : : > > | | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > Figure 7: UDP Encapsulated Binding Management Message Format > > > > Which looks like a copy/paste of the ESP specification [RFC4303]: > > > > 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 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- > - > > | Security Parameters Index (SPI) | > ^Int. > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |Cov- > > | Sequence Number | > |ered > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | - > --- > > | Payload Data* (variable) | | > ^ > > ~ ~ | > | > > | | > |Conf. > > + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |Cov- > > | | Padding (0-255 bytes) | > |ered* > > +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | > | > > | | Pad Length | Next Header | v > v > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- > --- > > | Integrity Check Value-ICV (variable) | > > ~ ~ > > | | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > Figure 1. Top-Level Format of an ESP Packet > > > > > > So the question is: Is your intent to provide a UDP encapsulation > format for the already specified ESP protocol, or to provide an > alternative encapsulation format to ESP? > > > > --julien > > _______________________________________________ > > MEXT mailing list > > MEXT@ietf.org > > https://www.ietf.org/mailman/listinfo/mext >=20 > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext From suresh.krishnan@ericsson.com Wed Jan 26 15:30:35 2011 Return-Path: <suresh.krishnan@ericsson.com> X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E70BB3A6A04 for <mext@core3.amsl.com>; Wed, 26 Jan 2011 15:30:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.543 X-Spam-Level: X-Spam-Status: No, score=-102.543 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lA18x8NxCBZI for <mext@core3.amsl.com>; Wed, 26 Jan 2011 15:30:35 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by core3.amsl.com (Postfix) with ESMTP id F3F663A69FA for <mext@ietf.org>; Wed, 26 Jan 2011 15:30:34 -0800 (PST) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p0R0E9mu028853; Wed, 26 Jan 2011 18:14:27 -0600 Received: from [142.133.10.107] (147.117.20.213) by eusaamw0712.eamcs.ericsson.se (147.117.20.182) with Microsoft SMTP Server id 8.2.234.1; Wed, 26 Jan 2011 18:33:26 -0500 Message-ID: <4D40AF02.80407@ericsson.com> Date: Wed, 26 Jan 2011 18:32:18 -0500 From: Suresh Krishnan <suresh.krishnan@ericsson.com> User-Agent: Thunderbird 2.0.0.24 (X11/20101027) MIME-Version: 1.0 To: marcelo bagnulo braun <marcelo@it.uc3m.es> References: <4D3DD426.6080107@it.uc3m.es> In-Reply-To: <4D3DD426.6080107@it.uc3m.es> Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit Cc: mext <mext@ietf.org> Subject: Re: [MEXT] Call for WG adoption of I-D: draft-korhonen-mext-mip6-altsec X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG <mext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/mext> List-Post: <mailto:mext@ietf.org> List-Help: <mailto:mext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 26 Jan 2011 23:30:36 -0000 Hi Chairs, On 11-01-24 02:33 PM, marcelo bagnulo braun wrote: > The ID has had 3 reviews as we require. > So, we are now ready to ask the WG if they think we should adopt the > document. > > Please express your opinion before monday 31st jan. I support the adoption of this draft as a mext wg document. Thanks Suresh From ahmad.muhanna@ericsson.com Wed Jan 26 16:55:41 2011 Return-Path: <ahmad.muhanna@ericsson.com> X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CEE1828B56A for <mext@core3.amsl.com>; Wed, 26 Jan 2011 16:55:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WVnhyVd7TbrU for <mext@core3.amsl.com>; Wed, 26 Jan 2011 16:55:41 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by core3.amsl.com (Postfix) with ESMTP id E8F033A68BD for <mext@ietf.org>; Wed, 26 Jan 2011 16:55:40 -0800 (PST) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p0R1dW1d003291; Wed, 26 Jan 2011 19:39:34 -0600 Received: from EUSAACMS0714.eamcs.ericsson.se ([169.254.1.96]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Wed, 26 Jan 2011 19:58:35 -0500 From: Ahmad Muhanna <ahmad.muhanna@ericsson.com> To: "Laganier, Julien" <julienl@qualcomm.com>, mext <mext@ietf.org> Date: Wed, 26 Jan 2011 19:58:33 -0500 Thread-Topic: [MEXT] Call for WG adoption of I-D: draft-korhonen-mext-mip6-altsec Thread-Index: Acu7/axaxR2jwXP8TX6XUui7vvi6UQBv3PdA Message-ID: <1FCAE7B6027FE3489B8497A060C704C431D1A216F7@EUSAACMS0714.eamcs.ericsson.se> References: <4D3DD426.6080107@it.uc3m.es> In-Reply-To: <4D3DD426.6080107@it.uc3m.es> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [MEXT] Call for WG adoption of I-D: draft-korhonen-mext-mip6-altsec X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG <mext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/mext> List-Post: <mailto:mext@ietf.org> List-Help: <mailto:mext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 27 Jan 2011 00:55:41 -0000 Hello Chairs, I support adopting this draft as a WG document.=20 Regards, Ahmad -----Original Message----- From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of mar= celo bagnulo braun Sent: Monday, January 24, 2011 11:34 AM To: mext Subject: [MEXT] Call for WG adoption of I-D: draft-korhonen-mext-mip6-altse= c The ID has had 3 reviews as we require. So, we are now ready to ask the WG if they think we should adopt the docum= ent. Please express your opinion before monday 31st jan. Reviews can be found: The I-D: draft-korhonen-mext-mip6-altsec-06 has been reviewed by: 1. Jan Zorz http://www.ietf.org/mail-archive/web/mext/current/msg04489.html 2. Domagoz Premec http://www.ietf.org/mail-archive/web/mext/current/msg04457.html 3. Ryuji Wakikawa http://www.ietf.org/mail-archive/web/mext/current/msg04470.html _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From Fred.L.Templin@boeing.com Thu Jan 27 08:12:18 2011 Return-Path: <Fred.L.Templin@boeing.com> X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D12AC3A690A for <mext@core3.amsl.com>; Thu, 27 Jan 2011 08:12:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.472 X-Spam-Level: X-Spam-Status: No, score=-6.472 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AFMQlw4SOx9O for <mext@core3.amsl.com>; Thu, 27 Jan 2011 08:12:18 -0800 (PST) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by core3.amsl.com (Postfix) with ESMTP id EE2863A67D3 for <mext@ietf.org>; Thu, 27 Jan 2011 08:12:17 -0800 (PST) Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by blv-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p0RGFITD022510 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 27 Jan 2011 08:15:19 -0800 (PST) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id p0RGFI4h019889; Thu, 27 Jan 2011 08:15:18 -0800 (PST) Received: from XCH-NWHT-03.nw.nos.boeing.com (xch-nwht-03.nw.nos.boeing.com [130.247.71.23]) by slb-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p0RGFHEe019862 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Thu, 27 Jan 2011 08:15:18 -0800 (PST) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-03.nw.nos.boeing.com ([130.247.71.23]) with mapi; Thu, 27 Jan 2011 08:15:17 -0800 From: "Templin, Fred L" <Fred.L.Templin@boeing.com> To: "Laganier, Julien" <julienl@qualcomm.com> Date: Thu, 27 Jan 2011 08:15:15 -0800 Thread-Topic: [MEXT] Call for WG adoption ofI-D: draft-korhonen-mext-mip6-altsec Thread-Index: AQHLvS5ioJLiiK5cIUOVOwObIMivn5Pj4vDwgAEdItA= Message-ID: <E1829B60731D1740BB7A0626B4FAF0A65C682838DC@XCH-NW-01V.nw.nos.boeing.com> References: <878vyarmku.fsf@natisbad.org><C963527A.D013%basavaraj.patil@noki a.com><98A16B2D00B5724F81E80EF1927A029703E3FB@nasanexd01e.na.qualcomm.com><06CCEF13-4E11-474D-A25E-C1425D5B520A@gmail.com> <98A16B2D00B5724F81E80EF1927A029703EAD4@nasanexd01e.na.qualcomm.com> In-Reply-To: <98A16B2D00B5724F81E80EF1927A029703EAD4@nasanexd01e.na.qualcomm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mext@ietf.org" <mext@ietf.org> Subject: Re: [MEXT] Call for WG adoption ofI-D: draft-korhonen-mext-mip6-altsec X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG <mext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/mext> List-Post: <mailto:mext@ietf.org> List-Help: <mailto:mext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 27 Jan 2011 16:12:18 -0000 =20 Julien, > without of course using this argument to reject improvements. I couldn't agree more! Fred= From georg.hampel@alcatel-lucent.com Thu Jan 27 11:19:00 2011 Return-Path: <georg.hampel@alcatel-lucent.com> X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D5D728C157 for <mext@core3.amsl.com>; Thu, 27 Jan 2011 11:19:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.584 X-Spam-Level: X-Spam-Status: No, score=-6.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y7GJKnMGBGgY for <mext@core3.amsl.com>; Thu, 27 Jan 2011 11:18:58 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id 6C9193A69A2 for <mext@ietf.org>; Thu, 27 Jan 2011 11:18:58 -0800 (PST) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id p0RJM1nb016340 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <mext@ietf.org>; Thu, 27 Jan 2011 13:22:02 -0600 (CST) Received: from USNAVSXCHHUB03.ndc.alcatel-lucent.com (usnavsxchhub03.ndc.alcatel-lucent.com [135.3.39.112]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p0RJLgwb005949 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for <mext@ietf.org>; Thu, 27 Jan 2011 13:22:01 -0600 Received: from USNAVSXCHMBSA2.ndc.alcatel-lucent.com ([135.3.39.127]) by USNAVSXCHHUB03.ndc.alcatel-lucent.com ([135.3.39.112]) with mapi; Thu, 27 Jan 2011 13:21:55 -0600 From: "Hampel, K Georg (K Georg)" <georg.hampel@alcatel-lucent.com> To: "mext@ietf.org" <mext@ietf.org> Date: Thu, 27 Jan 2011 13:21:52 -0600 Thread-Topic: [MEXT] reduce mobility header size Thread-Index: Acu5Qnn+9dPaMpYBS8GtIoosYVfgMQFFFA3w Message-ID: <154773479ED2314980CB638A48FC4434833BAA1C@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> References: <154773479ED2314980CB638A48FC44348334CFA2@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <87d3nq3cp9.fsf@natisbad.org> In-Reply-To: <87d3nq3cp9.fsf@natisbad.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Subject: Re: [MEXT] reduce mobility header size X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG <mext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/mext> List-Post: <mailto:mext@ietf.org> List-Help: <mailto:mext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 27 Jan 2011 19:19:00 -0000 All, RFC 3775 makes RH2 and HAO headers on payload packets only a SHOULD require= ment! It doesn't provide any regulation on how MN/CN should proceed when su= ch headers are missing. When omitting these headers, the packet looks like an ordinary transport pa= cket on the wire, but it carries an INCORRECT transport header checksum. Th= is means that certain middle boxes may discard the packet which is undesira= ble. I therefore propose the following: 1) In RO, a sending host MAY omit HAO and RH2 headers on payload packets. 2) When omitting these headers, the checksum of the lowest transport header= MUST be matched to the actual IP header of the packet, i.e. the pseudo hea= der must be based on CoA rather than HoA. 3) In case the transport protocol is ESP or AH, the host MUST proceed accor= ding to: http://tools.ietf.org/html/draft-ebalard-mext-ipsec-ro-02. This means that the sending host must recompute the transport-header checks= um of packets it receives from the transport layer. The receiving host sear= ches the binding entries based on the packet's on-the-wire IP addresses (i.= e. CoA instead of HoA). If such an entry exists, the host recomputes the ch= ecksum using the HoA from this entry before passing the packet up to the tr= ansport layer. In this manner, the higher protocol layers don't feel disturbed and middle-= box collisions are avoided! Regards, -Georg -----Original Message----- From: Arnaud Ebalard [mailto:arno@natisbad.org]=20 Sent: Friday, January 21, 2011 3:04 AM To: Hampel, K Georg (K Georg) Cc: mext@ietf.org; Klein, Thierry E (Thierry) Subject: Re: [MEXT] reduce mobility header size Hi, "Hampel, K Georg (K Georg)" <georg.hampel@alcatel-lucent.com> writes: > Is there currently any effort to reduce the mobility header size in > route optimization? Thanks. Do you mean the presence of RH2 and HAO in DestOpt in the packets? If you intend *to use IPsec/IKE between the peers*, I proposed a solution to remove RH2 and HAO in DestOpt from packets and also the need for HoTI/HoT in the following draft:=20 http://tools.ietf.org/html/draft-ebalard-mext-ipsec-ro-02 For a simple introduction (description, advantages, drawbacks),=20 http://natisbad.org/IRO/ Cheers, a+ From Fred.L.Templin@boeing.com Thu Jan 27 12:57:49 2011 Return-Path: <Fred.L.Templin@boeing.com> X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFCFC3A6A5E for <mext@core3.amsl.com>; Thu, 27 Jan 2011 12:57:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.471 X-Spam-Level: X-Spam-Status: No, score=-6.471 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id otJlZCQgC4Lc for <mext@core3.amsl.com>; Thu, 27 Jan 2011 12:57:48 -0800 (PST) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by core3.amsl.com (Postfix) with ESMTP id 8F7DC3A6A51 for <mext@ietf.org>; Thu, 27 Jan 2011 12:57:48 -0800 (PST) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by blv-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p0RL0oX7010981 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <mext@ietf.org>; Thu, 27 Jan 2011 13:00:50 -0800 (PST) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id p0RL0nnF014365 for <mext@ietf.org>; Thu, 27 Jan 2011 15:00:49 -0600 (CST) Received: from XCH-NWHT-10.nw.nos.boeing.com (xch-nwht-10.nw.nos.boeing.com [130.247.25.113]) by stl-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p0RL0ndW014336 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK) for <mext@ietf.org>; Thu, 27 Jan 2011 15:00:49 -0600 (CST) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-10.nw.nos.boeing.com ([130.247.25.113]) with mapi; Thu, 27 Jan 2011 13:00:49 -0800 From: "Templin, Fred L" <Fred.L.Templin@boeing.com> To: "mext@ietf.org" <mext@ietf.org> Date: Thu, 27 Jan 2011 13:00:47 -0800 Thread-Topic: IRON - a new approach to mobility management Thread-Index: Acu9ZObUeEtp4wpfT9m3W4BGslqdFwAIrYJQADbmZMA= Message-ID: <E1829B60731D1740BB7A0626B4FAF0A65C68283AB4@XCH-NW-01V.nw.nos.boeing.com> References: <AANLkTikGBOTOopf5g0SVvSe1-f1fBK38CN+mSnPdp+8D@mail.gmail.com> <E1829B60731D1740BB7A0626B4FAF0A65C682836E4@XCH-NW-01V.nw.nos.boeing.com> In-Reply-To: <E1829B60731D1740BB7A0626B4FAF0A65C682836E4@XCH-NW-01V.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [MEXT] IRON - a new approach to mobility management X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG <mext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/mext> List-Post: <mailto:mext@ietf.org> List-Help: <mailto:mext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 27 Jan 2011 20:57:49 -0000 Here is another aspect of the proposal that should be of interest to this community: http://www.ietf.org/id/draft-templin-ironmike-00.txt This shows how the IRON approach aligns with MOBIKE to present a system for managing VPN links that allows clients to connect to a nearby VPN gateway that in turn connects to a trusted and secure network. As clients change ISP connections, the VPN gateways naturally learn about the changes. As clients move significant distances, they simply discover and connect to a different nearby VPN gateway. Client-to-client communications then are conveyed across the trusted and secure network. Very simple; very few moving parts. Fred fred.l.templin@boeing.com=20 > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On=20 > Behalf Of Templin, Fred L > Sent: Wednesday, January 26, 2011 1:27 PM > To: mext@ietf.org > Subject: [MEXT] IRON - a new approach to mobility management >=20 > Hello, >=20 > I would like to introduce a new approach to mobility > management, which is an in-built feature of a new > routing and addressing system known as the Internet > Routing Overlay Network (IRON): >=20 > http://www.rfc-editor.org/internet-drafts/draft-templin-iron-17.txt >=20 > IRON is a product of the IRTF Routing Research Group > (RRG), which was chartered to provide recommendations > on addressing the Internet routing scaling issue. While > the IRON development effort focused primarily on routing > scaling, it soon became clear that mobility management > was also naturally afforded by the base architecture > with no need for adjunct mechanisms. Also, although this > fully-integrated proposal is new many of the concepts were > motivated by earlier works. The document therefore cites > related initiatives which explored similar concepts. >=20 > The IRON mobility management approach combines the best > aspects of both proactive and on-demand route discovery. > IRON Clients (which may include mobile end systems and > mobile routers) discover topologically-close IRON Serving > routers (i.e., "Servers") and create a connection with > one of the Servers for the purpose of maintaining=20 > bidirectional tunnel neighbor state. The Client then > registers one or more of its interfaces with the Server > so that the Server has handles for sending return traffic > to the Client. Since the Server can observe the public-side > address(es) of the Client without the Client needing to > discover them itself, the system therefore also naturally > supports a simplified form of NAT traversal.=20 >=20 > When a Client connects to the Server, the Server sends a > "link up" indication via a dynamic routing update that is > propagated to a core set of Relay routers (i.e., "Relays"). > In practice, there will be O(10's) of Relays while there > may be several orders of magnitude more Servers that are > topologically distributed throughout the Internet. Only > the Relays need maintain a full topology in their routing > tables; Servers need only maintain routing table entries > for their current set of connected Clients. >=20 > When a Client 'A' connected to Server 'Y' has a packet to > send to a new correspondent Client 'B' connected to Server > 'Z', 'A' first tunnels the packet to 'Y' as its default > router in the overlay network. Since 'Y' has only partial > topology information, it then tunnels the packet to a Relay > 'R'. Since 'R' has full topology knowledge, it then tunnels > the packet to 'Z' which in turn tunnels the packet to 'B'. > At the same time, 'Z' also returns a Redirect message to > inform 'Y' that 'Z' is a better next hop in the overlay > network to reach 'B'. If 'Y' is configured to forward > Redirects to its Clients, it then forwards the Redirect to > 'A' which then populates its routing tables with a more- > specific route. Otherwise, 'Y' uses the Redirect to update > its own routing tables. Hence, route optimization is > naturally supported. >=20 > When 'A' changes its ISP points of attachement (i.e., when > 'A' moves), it need not explicitly inform 'Y' of the changes > as long as it wishes to retain 'Y' as its Server, since 'Y' > will naturally discover any changes in 'A''s address(es) via > the source addresses of 'A''s packets. 'A' also need not > inform any of its recent correspondents about the changes, > since the correspondents can still reach 'A' via 'Y'. Hence, > localized mobility events are communicated implicitly and > immediately with no need for binding updates. >=20 > When 'A' moves far away from 'Y', it can leisurely discover > a new nearby Server 'W'. It can then connect to 'W' and > disconnect from 'Y' which will cause dynamic routing between > the overlay network Relays to naturally update 'A''s > Client-to-Server bindings. Hence, routing stretch is > managed without need for delay-sensitive actions. >=20 > Finally, the base system does not require Client-to-Client > binding updates. For example, if Client 'C' has a routing > table for 'A' with next-hop 'Y', but 'A' has moved to a > new Server 'W', 'C' will receive Redirect messages from > 'Y' informing it that 'A' is now associated with 'W'. > Hence, 'A' need not keep track of recent correspondents, > since any correspondents will naturally be redirected to > 'A's new location without risk of packet loss. (Again, > this is a coarse-grained mobility consideration, since > 'A' will typically not change to a new Server unless it > moves some significant distance, e.g., 1000 miles). >=20 > Comments and questions welcome, >=20 > Fred > fred.l.etmplin@boeing.com > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > = From wwwrun@rfc-editor.org Fri Jan 28 09:31:11 2011 Return-Path: <wwwrun@rfc-editor.org> X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B36633A68EF; Fri, 28 Jan 2011 09:31:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.008 X-Spam-Level: X-Spam-Status: No, score=-102.008 tagged_above=-999 required=5 tests=[AWL=-0.008, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pVrz0Wv9ZJ3I; Fri, 28 Jan 2011 09:31:11 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by core3.amsl.com (Postfix) with ESMTP id EBB6228C0CE; Fri, 28 Jan 2011 09:30:55 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id F05F5E0739; Fri, 28 Jan 2011 09:34:02 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20110128173402.F05F5E0739@rfc-editor.org> Date: Fri, 28 Jan 2011 09:34:02 -0800 (PST) Cc: mext@ietf.org, rfc-editor@rfc-editor.org Subject: [MEXT] RFC 6088 on Traffic Selectors for Flow Bindings X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG <mext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/mext> List-Post: <mailto:mext@ietf.org> List-Help: <mailto:mext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 28 Jan 2011 17:31:11 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6088 Title: Traffic Selectors for Flow Bindings Author: G. Tsirtsis, G. Giarreta, H. Soliman, N. Montavont Status: Standards Track Stream: IETF Date: January 2011 Mailbox: tsirtsis@qualcomm.com, gerardog@qualcomm.com, hesham@elevatemobile.com, nicolas.montavont@telecom-bretagne.eu Pages: 13 Characters: 28040 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-mext-binary-ts-05.txt URL: http://www.rfc-editor.org/rfc/rfc6088.txt This document defines binary formats for IPv4 and IPv6 traffic selectors to be used in conjunction with flow bindings for Mobile IPv6. [STANDARDS-TRACK] This document is a product of the Mobility EXTensions for IPv6 Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From wwwrun@rfc-editor.org Fri Jan 28 09:31:18 2011 Return-Path: <wwwrun@rfc-editor.org> X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21EFB3A68CB; Fri, 28 Jan 2011 09:31:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.008 X-Spam-Level: X-Spam-Status: No, score=-102.008 tagged_above=-999 required=5 tests=[AWL=-0.008, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sbI4HjRcCbpD; Fri, 28 Jan 2011 09:31:17 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by core3.amsl.com (Postfix) with ESMTP id C45BD3A691A; Fri, 28 Jan 2011 09:31:10 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id C4607E0743; Fri, 28 Jan 2011 09:34:17 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20110128173417.C4607E0743@rfc-editor.org> Date: Fri, 28 Jan 2011 09:34:17 -0800 (PST) Cc: mext@ietf.org, rfc-editor@rfc-editor.org Subject: [MEXT] RFC 6089 on Flow Bindings in Mobile IPv6 and Network Mobility (NEMO) Basic Support X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG <mext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/mext> List-Post: <mailto:mext@ietf.org> List-Help: <mailto:mext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 28 Jan 2011 17:31:18 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6089 Title: Flow Bindings in Mobile IPv6 and Network Mobility (NEMO) Basic Support Author: G. Tsirtsis, H. Soliman, N. Montavont, G. Giaretta, K. Kuladinithi Status: Standards Track Stream: IETF Date: January 2011 Mailbox: tsirtsis@qualcomm.com, hesham@elevatemobile.com, nicolas.montavont@telecom-bretagne.eu, gerardog@qualcomm.com, koo@comnets.uni-bremen.de Pages: 31 Characters: 69353 Updates: RFC5648 I-D Tag: draft-ietf-mext-flow-binding-11.txt URL: http://www.rfc-editor.org/rfc/rfc6089.txt This document introduces extensions to Mobile IPv6 that allow nodes to bind one or more flows to a care-of address. These extensions allow multihomed nodes to instruct home agents and other Mobile IPv6 entities to direct inbound flows to specific addresses. [STANDARDS- TRACK] This document is a product of the Mobility EXTensions for IPv6 Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From jouni.nospam@gmail.com Fri Jan 28 14:21:50 2011 Return-Path: <jouni.nospam@gmail.com> X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F3E013A68BD for <mext@core3.amsl.com>; Fri, 28 Jan 2011 14:21:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.487 X-Spam-Level: X-Spam-Status: No, score=-3.487 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hV9T41T56VBZ for <mext@core3.amsl.com>; Fri, 28 Jan 2011 14:21:44 -0800 (PST) Received: from vs12.mail.saunalahti.fi (vs12.mail.saunalahti.fi [195.197.172.107]) by core3.amsl.com (Postfix) with ESMTP id 7F51D3A689E for <mext@ietf.org>; Fri, 28 Jan 2011 14:21:43 -0800 (PST) Received: from saunalahti-vams (localhost [127.0.0.1]) by vs12.mail.saunalahti.fi (Postfix) with SMTP id AE8EC1A905C; Sat, 29 Jan 2011 00:24:49 +0200 (EET) Received: from vs12.mail.saunalahti.fi ([127.0.0.1]) by vs12.mail.saunalahti.fi ([195.197.172.107]) with SMTP (gateway) id A062BDAC0F7; Sat, 29 Jan 2011 00:24:49 +0200 Received: from gw03.mail.saunalahti.fi (gw03.mail.saunalahti.fi [195.197.172.111]) by vs12.mail.saunalahti.fi (Postfix) with ESMTP id A222F1A905C; Sat, 29 Jan 2011 00:24:49 +0200 (EET) Received: from a88-114-174-127.elisa-laajakaista.fi (a88-114-174-127.elisa-laajakaista.fi [88.114.174.127]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by gw03.mail.saunalahti.fi (Postfix) with ESMTP id 68017216962; Sat, 29 Jan 2011 00:24:43 +0200 (EET) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Jouni <jouni.nospam@gmail.com> In-Reply-To: <98A16B2D00B5724F81E80EF1927A02970409A1@nasanexd01e.na.qualcomm.com> Date: Sat, 29 Jan 2011 00:24:42 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <185D5B42-0A88-4CDB-8FFF-B49FD52D6DD5@gmail.com> References: <878vyarmku.fsf@natisbad.org> <C963527A.D013%basavaraj.patil@nokia.com> <98A16B2D00B5724F81E80EF1927A029703E3FB@nasanexd01e.na.qualcomm.com> <06CCEF13-4E11-474D-A25E-C1425D5B520A@gmail.com> <98A16B2D00B5724F81E80EF1927A029703EAD4@nasanexd01e.na.qualcomm.com> <98A16B2D00B5724F81E80EF1927A02970409A1@nasanexd01e.na.qualcomm.com> To: "Laganier, Julien" <julienl@qualcomm.com> X-Mailer: Apple Mail (2.1082) X-Antivirus: VAMS Cc: "mext@ietf.org" <mext@ietf.org>, "jan@go6.si" <jan@go6.si>, "Basavaraj.Patil@nokia.com" <Basavaraj.Patil@nokia.com> Subject: Re: [MEXT] Call for WG adoption of I-D: draft-korhonen-mext-mip6-altsec X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG <mext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/mext> List-Post: <mailto:mext@ietf.org> List-Help: <mailto:mext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 28 Jan 2011 22:21:50 -0000 Just a question for my clarification. Do you mean simply taking the UDP = encap + ESP format or also inheriting everything those respective RFCs = say about their processing etc? - JOuni On Jan 28, 2011, at 9:18 PM, Laganier, Julien wrote: > Hello again, >=20 > Thought that maybe making my question a bit more specific would help:=20= >=20 > So, why don't you simply define a UDP encapsulation to ESP, instead of = duplicating ESP functionality into your framework? >=20 > --julien >=20 > Laganier, Julien wrote: >>=20 >> Hi Jouni, >>=20 >> I understand you "follow the ESP format but feel no shame on changing >> it if we see a reason to do so", but I am (shamelessly ;) wondering >> about the actual reason to do so, as per one of the famous >> Architectural Principles of the Internet documented in RFC 1958: >>=20 >> 3.2 If there are several ways of doing the same thing, choose one. >> If a previous design, in the Internet context or elsewhere, has >> successfully solved the same problem, choose the same solution = unless >> there is a good technical reason not to. Duplication of the same >> protocol functionality should be avoided as far as possible, = without >> of course using this argument to reject improvements. >>=20 >> Would you mind enlightening us? >>=20 >> --julien >>=20 >> jouni korhonen wrote: >>>=20 >>> Few things. The draft already states that "The Padding, Pad Length, >>> Next Header and ICV fields follow the rules of Section 2.4 to 2.8 of >>> [RFC4303] unless otherwise stated in this document." So, we follow >>> the ESP format but feel no shame on changing it if we see a reason >>> to do so. >>>=20 >>> The reason why we chose to do it like this was two fold: 1) some >>> ciphers etc when used would need ~equivalent encapsulation anyway. >>> 2) if we had come up with our very own format the question on the >>> list would have been "why not using RFC4303 encapsulation format". >>> Actually.. the latter already happened offline. >>>=20 >>> - Jouni >>>=20 >>>=20 >>> On Jan 26, 2011, at 12:48 AM, Laganier, Julien wrote: >>>=20 >>>> Hi Raj, >>>>=20 >>>>> Inline: >>>>>=20 >>>>> On 1/24/11 3:58 PM, "ext Arnaud Ebalard" <arno@natisbad.org> >> wrote: >>>>>=20 >>>>>>=20 >>>>>> To me, what the draft describes is a patchwork based on MIPv6, >> ESP >>> and >>>>>> TLS. Instead of building on top of those protocols (read >> modularity >>>>> and >>>>>> interoperability), it reuses (hijacks) various blocks of >> associated >>>>>> standards in a non-modular way. For instance, one has to >>> reimplement >>>>> ESP >>>>>> in userspace to support the protocol. >>>>>=20 >>>>> We are specifying an encapsulation method in the I-D. To say that >>> one >>>>> has to reimplement ESP in userspace is incorrect. >>>>=20 >>>> The encapsulation format you have in the I-D is: >>>>=20 >>>> 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 >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> | | >>>> : IPv4 or IPv6 header (src-addr=3DXa, dst-addr=3DYa) = : >>>> | | >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> | | >>>> : UDP header (src-port=3DXp,dst-port=3DYp) = : >>>> | | >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - >> -- >>> --- >>>> |PType=3D8| SPI | >>> ^Int. >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> |Cov- >>>> | Sequence Number | >>> |ered >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | >> - >>> --- >>>> | Payload Data* (variable) | | >>> ^ >>>> : : | >>> | >>>> | | >>> |Conf. >>>> + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> |Cov- >>>> | | Padding (0-255 bytes) | >>> |ered* >>>> +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | >>> | >>>> | | Pad Length | Next Header | v >>> v >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - >> -- >>> --- >>>> | Integrity Check Value-ICV (variable) | >>>> : : >>>> | | >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>=20 >>>> Figure 7: UDP Encapsulated Binding Management Message Format >>>>=20 >>>> Which looks like a copy/paste of the ESP specification [RFC4303]: >>>>=20 >>>> 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 >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - >> -- >>> - >>>> | Security Parameters Index (SPI) | >>> ^Int. >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> |Cov- >>>> | Sequence Number | >>> |ered >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | >> - >>> --- >>>> | Payload Data* (variable) | | >>> ^ >>>> ~ ~ | >>> | >>>> | | >>> |Conf. >>>> + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> |Cov- >>>> | | Padding (0-255 bytes) | >>> |ered* >>>> +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | >>> | >>>> | | Pad Length | Next Header | v >>> v >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - >> -- >>> --- >>>> | Integrity Check Value-ICV (variable) | >>>> ~ ~ >>>> | | >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>=20 >>>> Figure 1. Top-Level Format of an ESP Packet >>>>=20 >>>>=20 >>>> So the question is: Is your intent to provide a UDP encapsulation >>> format for the already specified ESP protocol, or to provide an >>> alternative encapsulation format to ESP? >>>>=20 >>>> --julien >>>> _______________________________________________ >>>> MEXT mailing list >>>> MEXT@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mext >>>=20 >>> _______________________________________________ >>> MEXT mailing list >>> MEXT@ietf.org >>> https://www.ietf.org/mailman/listinfo/mext >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext From julienl@qualcomm.com Fri Jan 28 11:15:33 2011 Return-Path: <julienl@qualcomm.com> X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E040D3A6946 for <mext@core3.amsl.com>; Fri, 28 Jan 2011 11:15:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.408 X-Spam-Level: X-Spam-Status: No, score=-106.408 tagged_above=-999 required=5 tests=[AWL=0.191, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7cUYX+WdNPz1 for <mext@core3.amsl.com>; Fri, 28 Jan 2011 11:15:32 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 93A573A68D7 for <mext@ietf.org>; Fri, 28 Jan 2011 11:15:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1296242319; x=1327778319; h=from:to:cc:subject:thread-topic:thread-index:date: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: x-originating-ip:content-type:content-transfer-encoding: mime-version; z=From:=20"Laganier,=20Julien"=20<julienl@qualcomm.com> |To:=20jouni=20korhonen=20<jouni.nospam@gmail.com>|CC:=20 "Basavaraj.Patil@nokia.com"=20<Basavaraj.Patil@nokia.com> ,=20"jan@go6.si"=0D=0A=09<jan@go6.si>,=20"mext@ietf.org" =20<mext@ietf.org>|Subject:=20RE:=20[MEXT]=20Call=20for =20WG=20adoption=20of=09I-D:=0D=0A=09draft-korhonen-mext- mip6-altsec|Thread-Topic:=20[MEXT]=20Call=20for=20WG=20ad option=20of=09I-D:=0D=0A=09draft-korhonen-mext-mip6-altse c|Thread-Index:=20AQHLvyAryG5ore7yf067DtSh/6mg0Q=3D=3D |Date:=20Fri,=2028=20Jan=202011=2019:18:39=20+0000 |Message-ID:=20<98A16B2D00B5724F81E80EF1927A02970409A1@na sanexd01e.na.qualcomm.com>|References:=20<878vyarmku.fsf@ natisbad.org>=0D=0A=09<C963527A.D013%basavaraj.patil@noki a.com>=0D=0A=09<98A16B2D00B5724F81E80EF1927A029703E3FB@na sanexd01e.na.qualcomm.com>=0D=0A=09<06CCEF13-4E11-474D-A2 5E-C1425D5B520A@gmail.com>=0D=0A=20<98A16B2D00B5724F81E80 EF1927A029703EAD4@nasanexd01e.na.qualcomm.com> |In-Reply-To:=20<98A16B2D00B5724F81E80EF1927A029703EAD4@n asanexd01e.na.qualcomm.com>|Accept-Language:=20en-US |Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|x-originating-ip:=20[172.30.39.5] |Content-Type:=20text/plain=3B=20charset=3D"us-ascii" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=k5Lfm1dS50Onb2nRB19zjvCb212ICzexxeD7L6/OsfA=; b=aLwka+B0PA6fMKVdMySfxJh/i56b/gMTPhw38Z9+DpFHmZSdkSejZtds xSZ1zMLMb5xt3IDF5HaZgD6Qoj9wCSzWy6GtCe1JOg8IOgp2Si7Xb9seu qo5GaqcqQOqP1z916vBm4255n2bkR7kmHD/yDIaiQ7WG4r3a4SHnX4ZDw Y=; X-IronPort-AV: E=McAfee;i="5400,1158,6240"; a="72375772" Received: from ironmsg03-r.qualcomm.com ([172.30.46.17]) by wolverine01.qualcomm.com with ESMTP; 28 Jan 2011 11:18:39 -0800 X-IronPort-AV: E=Sophos;i="4.60,392,1291622400"; d="scan'208";a="45497115" Received: from nasanexhc09.na.qualcomm.com ([172.30.39.8]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/AES128-SHA; 28 Jan 2011 11:18:39 -0800 Received: from NASANEXD01E.na.qualcomm.com ([fe80::6555:8c37:4ee3:efc4]) by nasanexhc09.na.qualcomm.com ([::1]) with mapi id 14.01.0218.012; Fri, 28 Jan 2011 11:18:39 -0800 From: "Laganier, Julien" <julienl@qualcomm.com> To: jouni korhonen <jouni.nospam@gmail.com> Thread-Topic: [MEXT] Call for WG adoption of I-D: draft-korhonen-mext-mip6-altsec Thread-Index: AQHLvyAryG5ore7yf067DtSh/6mg0Q== Date: Fri, 28 Jan 2011 19:18:39 +0000 Message-ID: <98A16B2D00B5724F81E80EF1927A02970409A1@nasanexd01e.na.qualcomm.com> References: <878vyarmku.fsf@natisbad.org> <C963527A.D013%basavaraj.patil@nokia.com> <98A16B2D00B5724F81E80EF1927A029703E3FB@nasanexd01e.na.qualcomm.com> <06CCEF13-4E11-474D-A25E-C1425D5B520A@gmail.com> <98A16B2D00B5724F81E80EF1927A029703EAD4@nasanexd01e.na.qualcomm.com> In-Reply-To: <98A16B2D00B5724F81E80EF1927A029703EAD4@nasanexd01e.na.qualcomm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.30.39.5] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Fri, 28 Jan 2011 14:27:26 -0800 Cc: "mext@ietf.org" <mext@ietf.org>, "jan@go6.si" <jan@go6.si>, "Basavaraj.Patil@nokia.com" <Basavaraj.Patil@nokia.com> Subject: Re: [MEXT] Call for WG adoption of I-D: draft-korhonen-mext-mip6-altsec X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG <mext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/mext> List-Post: <mailto:mext@ietf.org> List-Help: <mailto:mext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 28 Jan 2011 19:15:34 -0000 Hello again, Thought that maybe making my question a bit more specific would help:=20 So, why don't you simply define a UDP encapsulation to ESP, instead of dupl= icating ESP functionality into your framework? --julien Laganier, Julien wrote: >=20 > Hi Jouni, >=20 > I understand you "follow the ESP format but feel no shame on changing > it if we see a reason to do so", but I am (shamelessly ;) wondering > about the actual reason to do so, as per one of the famous > Architectural Principles of the Internet documented in RFC 1958: >=20 > 3.2 If there are several ways of doing the same thing, choose one. > If a previous design, in the Internet context or elsewhere, has > successfully solved the same problem, choose the same solution unless > there is a good technical reason not to. Duplication of the same > protocol functionality should be avoided as far as possible, without > of course using this argument to reject improvements. >=20 > Would you mind enlightening us? > > --julien > > jouni korhonen wrote: > > > > Few things. The draft already states that "The Padding, Pad Length, > > Next Header and ICV fields follow the rules of Section 2.4 to 2.8 of > > [RFC4303] unless otherwise stated in this document." So, we follow > > the ESP format but feel no shame on changing it if we see a reason > > to do so. > > > > The reason why we chose to do it like this was two fold: 1) some > > ciphers etc when used would need ~equivalent encapsulation anyway. > > 2) if we had come up with our very own format the question on the > > list would have been "why not using RFC4303 encapsulation format". > > Actually.. the latter already happened offline. > > > > - Jouni > > > > > > On Jan 26, 2011, at 12:48 AM, Laganier, Julien wrote: > > > > > Hi Raj, > > > > > >> Inline: > > >> > > >> On 1/24/11 3:58 PM, "ext Arnaud Ebalard" <arno@natisbad.org> > wrote: > > >> > > >>> > > >>> To me, what the draft describes is a patchwork based on MIPv6, > ESP > > and > > >>> TLS. Instead of building on top of those protocols (read > modularity > > >> and > > >>> interoperability), it reuses (hijacks) various blocks of > associated > > >>> standards in a non-modular way. For instance, one has to > > reimplement > > >> ESP > > >>> in userspace to support the protocol. > > >> > > >> We are specifying an encapsulation method in the I-D. To say that > > one > > >> has to reimplement ESP in userspace is incorrect. > > > > > > The encapsulation format you have in the I-D is: > > > > > > 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 > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | | > > > : IPv4 or IPv6 header (src-addr=3DXa, dst-addr=3DYa) : > > > | | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | | > > > : UDP header (src-port=3DXp,dst-port=3DYp) : > > > | | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - > -- > > --- > > > |PType=3D8| SPI | > > ^Int. > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > |Cov- > > > | Sequence Number | > > |ered > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | > - > > --- > > > | Payload Data* (variable) | | > > ^ > > > : : | > > | > > > | | > > |Conf. > > > + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > |Cov- > > > | | Padding (0-255 bytes) | > > |ered* > > > +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | > > | > > > | | Pad Length | Next Header | v > > v > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - > -- > > --- > > > | Integrity Check Value-ICV (variable) | > > > : : > > > | | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > > Figure 7: UDP Encapsulated Binding Management Message Format > > > > > > Which looks like a copy/paste of the ESP specification [RFC4303]: > > > > > > 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 > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - > -- > > - > > > | Security Parameters Index (SPI) | > > ^Int. > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > |Cov- > > > | Sequence Number | > > |ered > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | > - > > --- > > > | Payload Data* (variable) | | > > ^ > > > ~ ~ | > > | > > > | | > > |Conf. > > > + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > |Cov- > > > | | Padding (0-255 bytes) | > > |ered* > > > +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | > > | > > > | | Pad Length | Next Header | v > > v > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - > -- > > --- > > > | Integrity Check Value-ICV (variable) | > > > ~ ~ > > > | | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > > Figure 1. Top-Level Format of an ESP Packet > > > > > > > > > So the question is: Is your intent to provide a UDP encapsulation > > format for the already specified ESP protocol, or to provide an > > alternative encapsulation format to ESP? > > > > > > --julien > > > _______________________________________________ > > > MEXT mailing list > > > MEXT@ietf.org > > > https://www.ietf.org/mailman/listinfo/mext > > > > _______________________________________________ > > MEXT mailing list > > MEXT@ietf.org > > https://www.ietf.org/mailman/listinfo/mext > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext From julienl@qualcomm.com Fri Jan 28 14:26:47 2011 Return-Path: <julienl@qualcomm.com> X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C8363A697E for <mext@core3.amsl.com>; Fri, 28 Jan 2011 14:26:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.415 X-Spam-Level: X-Spam-Status: No, score=-106.415 tagged_above=-999 required=5 tests=[AWL=0.184, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c2-LItoUA0YU for <mext@core3.amsl.com>; Fri, 28 Jan 2011 14:26:43 -0800 (PST) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 7C6313A6939 for <mext@ietf.org>; Fri, 28 Jan 2011 14:26:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1296253790; x=1327789790; h=from:to:cc:subject:thread-topic:thread-index:date: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: x-originating-ip:content-type:content-transfer-encoding: mime-version; z=From:=20"Laganier,=20Julien"=20<julienl@qualcomm.com> |To:=20Jouni=20<jouni.nospam@gmail.com>|CC:=20"Basavaraj. Patil@nokia.com"=20<Basavaraj.Patil@nokia.com>,=20"jan@go 6.si"=0D=0A=09<jan@go6.si>,=20"mext@ietf.org"=20<mext@iet f.org>,=20"arno@natisbad.org"=0D=0A=09<arno@natisbad.org> |Subject:=20RE:=20[MEXT]=20Call=20for=20WG=20adoption=20o f=09I-D:=0D=0A=20draft-korhonen-mext-mip6-altsec |Thread-Topic:=20[MEXT]=20Call=20for=20WG=20adoption=20of =09I-D:=0D=0A=20draft-korhonen-mext-mip6-altsec |Thread-Index:=20AQHLvzov3JMqMUYi50SJ29cdxJAzppPm9iVA |Date:=20Fri,=2028=20Jan=202011=2022:29:50=20+0000 |Message-ID:=20<98A16B2D00B5724F81E80EF1927A0297040A1E@na sanexd01e.na.qualcomm.com>|References:=20<878vyarmku.fsf@ natisbad.org>=0D=0A=20<C963527A.D013%basavaraj.patil@noki a.com>=0D=0A=20<98A16B2D00B5724F81E80EF1927A029703E3FB@na sanexd01e.na.qualcomm.com>=0D=0A=20<06CCEF13-4E11-474D-A2 5E-C1425D5B520A@gmail.com>=0D=0A=20<98A16B2D00B5724F81E80 EF1927A029703EAD4@nasanexd01e.na.qualcomm.com>=0D=0A=20<9 8A16B2D00B5724F81E80EF1927A02970409A1@nasanexd01e.na.qual comm.com>=0D=0A=20<185D5B42-0A88-4CDB-8FFF-B49FD52D6DD5@g mail.com>|In-Reply-To:=20<185D5B42-0A88-4CDB-8FFF-B49FD52 D6DD5@gmail.com>|Accept-Language:=20en-US |Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|x-originating-ip:=20[172.30.39.5] |Content-Type:=20text/plain=3B=20charset=3D"us-ascii" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=i2aLsPP90xWk2fkbKyApdCElAa/xNQbxYJJ/xpzdhYQ=; b=LWdczLjIieb4uW1BfhWyOk8qWbdiaPBYpbmLWXQ/969k/GOr1txt9sdV 4OpMM8qKRRoWEKl6Y1O0ePdUf0wEpz/NRsduXl4DYO38OyImZXDulkFqL 1ObQ54ZltwDGbZs8zjHwD/iI19wredUSFYZJhVNyiAPgs1bvREdgdpFG5 I=; X-IronPort-AV: E=McAfee;i="5400,1158,6240"; a="72182487" Received: from ironmsg03-r.qualcomm.com ([172.30.46.17]) by wolverine02.qualcomm.com with ESMTP; 28 Jan 2011 14:29:50 -0800 X-IronPort-AV: E=Sophos;i="4.60,392,1291622400"; d="scan'208";a="45539865" Received: from nasanexhc08.na.qualcomm.com ([172.30.39.7]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/AES128-SHA; 28 Jan 2011 14:29:50 -0800 Received: from NASANEXD01E.na.qualcomm.com ([fe80::6555:8c37:4ee3:efc4]) by nasanexhc08.na.qualcomm.com ([::1]) with mapi id 14.01.0218.012; Fri, 28 Jan 2011 14:29:50 -0800 From: "Laganier, Julien" <julienl@qualcomm.com> To: Jouni <jouni.nospam@gmail.com> Thread-Topic: [MEXT] Call for WG adoption of I-D: draft-korhonen-mext-mip6-altsec Thread-Index: AQHLvzov3JMqMUYi50SJ29cdxJAzppPm9iVA Date: Fri, 28 Jan 2011 22:29:50 +0000 Message-ID: <98A16B2D00B5724F81E80EF1927A0297040A1E@nasanexd01e.na.qualcomm.com> References: <878vyarmku.fsf@natisbad.org> <C963527A.D013%basavaraj.patil@nokia.com> <98A16B2D00B5724F81E80EF1927A029703E3FB@nasanexd01e.na.qualcomm.com> <06CCEF13-4E11-474D-A25E-C1425D5B520A@gmail.com> <98A16B2D00B5724F81E80EF1927A029703EAD4@nasanexd01e.na.qualcomm.com> <98A16B2D00B5724F81E80EF1927A02970409A1@nasanexd01e.na.qualcomm.com> <185D5B42-0A88-4CDB-8FFF-B49FD52D6DD5@gmail.com> In-Reply-To: <185D5B42-0A88-4CDB-8FFF-B49FD52D6DD5@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.30.39.5] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Fri, 28 Jan 2011 14:27:27 -0800 Cc: "mext@ietf.org" <mext@ietf.org>, "jan@go6.si" <jan@go6.si>, "Basavaraj.Patil@nokia.com" <Basavaraj.Patil@nokia.com> Subject: Re: [MEXT] Call for WG adoption of I-D: draft-korhonen-mext-mip6-altsec X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG <mext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/mext> List-Post: <mailto:mext@ietf.org> List-Help: <mailto:mext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 28 Jan 2011 22:26:47 -0000 Either.=20 IMHO both would be cleaner that the current approach. I understand the latt= er might also have some caveat but maybe they can be dealt with in an elega= nt manner, without introducing too much complexity, e.g., see Arnaud's m6t = (http://tools.ietf.org/html/draft-ebalard-mext-m6t-02.txt) --julien Jouni wrote:=20 >=20 > Just a question for my clarification. Do you mean simply taking the UDP > encap + ESP format or also inheriting everything those respective RFCs > say about their processing etc? >=20 > - JOuni >=20 >=20 > On Jan 28, 2011, at 9:18 PM, Laganier, Julien wrote: >=20 > > Hello again, > > > > Thought that maybe making my question a bit more specific would help: > > > > So, why don't you simply define a UDP encapsulation to ESP, instead > of duplicating ESP functionality into your framework? > > > > --julien > > > > Laganier, Julien wrote: > >> > >> Hi Jouni, > >> > >> I understand you "follow the ESP format but feel no shame on > changing > >> it if we see a reason to do so", but I am (shamelessly ;) wondering > >> about the actual reason to do so, as per one of the famous > >> Architectural Principles of the Internet documented in RFC 1958: > >> > >> 3.2 If there are several ways of doing the same thing, choose one. > >> If a previous design, in the Internet context or elsewhere, has > >> successfully solved the same problem, choose the same solution > unless > >> there is a good technical reason not to. Duplication of the same > >> protocol functionality should be avoided as far as possible, > without > >> of course using this argument to reject improvements. > >> > >> Would you mind enlightening us? > >> > >> --julien > >> > >> jouni korhonen wrote: > >>> > >>> Few things. The draft already states that "The Padding, Pad Length, > >>> Next Header and ICV fields follow the rules of Section 2.4 to 2.8 > of > >>> [RFC4303] unless otherwise stated in this document." So, we follow > >>> the ESP format but feel no shame on changing it if we see a reason > >>> to do so. > >>> > >>> The reason why we chose to do it like this was two fold: 1) some > >>> ciphers etc when used would need ~equivalent encapsulation anyway. > >>> 2) if we had come up with our very own format the question on the > >>> list would have been "why not using RFC4303 encapsulation format". > >>> Actually.. the latter already happened offline. > >>> > >>> - Jouni > >>> > >>> > >>> On Jan 26, 2011, at 12:48 AM, Laganier, Julien wrote: > >>> > >>>> Hi Raj, > >>>> > >>>>> Inline: > >>>>> > >>>>> On 1/24/11 3:58 PM, "ext Arnaud Ebalard" <arno@natisbad.org> > >> wrote: > >>>>> > >>>>>> > >>>>>> To me, what the draft describes is a patchwork based on MIPv6, > >> ESP > >>> and > >>>>>> TLS. Instead of building on top of those protocols (read > >> modularity > >>>>> and > >>>>>> interoperability), it reuses (hijacks) various blocks of > >> associated > >>>>>> standards in a non-modular way. For instance, one has to > >>> reimplement > >>>>> ESP > >>>>>> in userspace to support the protocol. > >>>>> > >>>>> We are specifying an encapsulation method in the I-D. To say that > >>> one > >>>>> has to reimplement ESP in userspace is incorrect. > >>>> > >>>> The encapsulation format you have in the I-D is: > >>>> > >>>> 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 > >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >>>> | | > >>>> : IPv4 or IPv6 header (src-addr=3DXa, dst-addr=3DYa) = : > >>>> | | > >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >>>> | | > >>>> : UDP header (src-port=3DXp,dst-port=3DYp) = : > >>>> | | > >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > - > >> -- > >>> --- > >>>> |PType=3D8| SPI | > >>> ^Int. > >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >>> |Cov- > >>>> | Sequence Number | > >>> |ered > >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | > >> - > >>> --- > >>>> | Payload Data* (variable) | > | > >>> ^ > >>>> : : > | > >>> | > >>>> | | > >>> |Conf. > >>>> + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >>> |Cov- > >>>> | | Padding (0-255 bytes) | > >>> |ered* > >>>> +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | > >>> | > >>>> | | Pad Length | Next Header | > v > >>> v > >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > - > >> -- > >>> --- > >>>> | Integrity Check Value-ICV (variable) | > >>>> : : > >>>> | | > >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >>>> > >>>> Figure 7: UDP Encapsulated Binding Management Message Format > >>>> > >>>> Which looks like a copy/paste of the ESP specification [RFC4303]: > >>>> > >>>> 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 > >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > - > >> -- > >>> - > >>>> | Security Parameters Index (SPI) | > >>> ^Int. > >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >>> |Cov- > >>>> | Sequence Number | > >>> |ered > >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | > >> - > >>> --- > >>>> | Payload Data* (variable) | > | > >>> ^ > >>>> ~ ~ > | > >>> | > >>>> | | > >>> |Conf. > >>>> + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >>> |Cov- > >>>> | | Padding (0-255 bytes) | > >>> |ered* > >>>> +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | > >>> | > >>>> | | Pad Length | Next Header | > v > >>> v > >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > - > >> -- > >>> --- > >>>> | Integrity Check Value-ICV (variable) | > >>>> ~ ~ > >>>> | | > >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >>>> > >>>> Figure 1. Top-Level Format of an ESP Packet > >>>> > >>>> > >>>> So the question is: Is your intent to provide a UDP encapsulation > >>> format for the already specified ESP protocol, or to provide an > >>> alternative encapsulation format to ESP? > >>>> > >>>> --julien > >>>> _______________________________________________ > >>>> MEXT mailing list > >>>> MEXT@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/mext > >>> > >>> _______________________________________________ > >>> MEXT mailing list > >>> MEXT@ietf.org > >>> https://www.ietf.org/mailman/listinfo/mext > >> _______________________________________________ > >> MEXT mailing list > >> MEXT@ietf.org > >> https://www.ietf.org/mailman/listinfo/mext From jouni.nospam@gmail.com Fri Jan 28 14:52:10 2011 Return-Path: <jouni.nospam@gmail.com> X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D530F3A68B7 for <mext@core3.amsl.com>; Fri, 28 Jan 2011 14:52:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.493 X-Spam-Level: X-Spam-Status: No, score=-3.493 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XZMAqtDUZ5ws for <mext@core3.amsl.com>; Fri, 28 Jan 2011 14:52:09 -0800 (PST) Received: from vs11.mail.saunalahti.fi (vs11.mail.saunalahti.fi [195.197.172.106]) by core3.amsl.com (Postfix) with ESMTP id F35C83A67EC for <mext@ietf.org>; Fri, 28 Jan 2011 14:52:08 -0800 (PST) Received: from saunalahti-vams (localhost [127.0.0.1]) by vs11.mail.saunalahti.fi (Postfix) with SMTP id E4A8F1A506A; Sat, 29 Jan 2011 00:55:14 +0200 (EET) Received: from vs11.mail.saunalahti.fi ([127.0.0.1]) by vs11.mail.saunalahti.fi ([195.197.172.106]) with SMTP (gateway) id A03EB7C98A2; Sat, 29 Jan 2011 00:55:01 +0200 Received: from gw03.mail.saunalahti.fi (gw03.mail.saunalahti.fi [195.197.172.111]) by vs11.mail.saunalahti.fi (Postfix) with ESMTP id BD9421A5058; Sat, 29 Jan 2011 00:55:01 +0200 (EET) Received: from a88-114-174-127.elisa-laajakaista.fi (a88-114-174-127.elisa-laajakaista.fi [88.114.174.127]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by gw03.mail.saunalahti.fi (Postfix) with ESMTP id 19A212169C0; Sat, 29 Jan 2011 00:54:55 +0200 (EET) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Jouni <jouni.nospam@gmail.com> In-Reply-To: <98A16B2D00B5724F81E80EF1927A0297040A1E@nasanexd01e.na.qualcomm.com> Date: Sat, 29 Jan 2011 00:54:55 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <B7C82145-9053-447A-BB4F-AB17D371BF64@gmail.com> References: <878vyarmku.fsf@natisbad.org> <C963527A.D013%basavaraj.patil@nokia.com> <98A16B2D00B5724F81E80EF1927A029703E3FB@nasanexd01e.na.qualcomm.com> <06CCEF13-4E11-474D-A25E-C1425D5B520A@gmail.com> <98A16B2D00B5724F81E80EF1927A029703EAD4@nasanexd01e.na.qualcomm.com> <98A16B2D00B5724F81E80EF1927A02970409A1@nasanexd01e.na.qualcomm.com> <185D5B42-0A88-4CDB-8FFF-B49FD52D6DD5@gmail.com> <98A16B2D00B5724F81E80EF1927A0297040A1E@nasanexd01e.na.qualcomm.com> To: "Laganier, Julien" <julienl@qualcomm.com> X-Mailer: Apple Mail (2.1082) X-Antivirus: VAMS Cc: "mext@ietf.org" <mext@ietf.org>, "jan@go6.si" <jan@go6.si>, "Basavaraj.Patil@nokia.com" <Basavaraj.Patil@nokia.com> Subject: Re: [MEXT] Call for WG adoption of I-D: draft-korhonen-mext-mip6-altsec X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG <mext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/mext> List-Post: <mailto:mext@ietf.org> List-Help: <mailto:mext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 28 Jan 2011 22:52:10 -0000 Hmm.. we do handle SPIs differently and our "ESP" can be absent even if = UDP encap is used. Would that be an issue regarding the reuse of = existing formats? - Jouni On Jan 29, 2011, at 12:29 AM, Laganier, Julien wrote: > Either.=20 >=20 > IMHO both would be cleaner that the current approach. I understand the = latter might also have some caveat but maybe they can be dealt with in = an elegant manner, without introducing too much complexity, e.g., see = Arnaud's m6t (http://tools.ietf.org/html/draft-ebalard-mext-m6t-02.txt) >=20 > --julien >=20 > Jouni wrote:=20 >>=20 >> Just a question for my clarification. Do you mean simply taking the = UDP >> encap + ESP format or also inheriting everything those respective = RFCs >> say about their processing etc? >>=20 >> - JOuni >>=20 >>=20 >> On Jan 28, 2011, at 9:18 PM, Laganier, Julien wrote: >>=20 >>> Hello again, >>>=20 >>> Thought that maybe making my question a bit more specific would = help: >>>=20 >>> So, why don't you simply define a UDP encapsulation to ESP, instead >> of duplicating ESP functionality into your framework? >>>=20 >>> --julien >>>=20 >>> Laganier, Julien wrote: >>>>=20 >>>> Hi Jouni, >>>>=20 >>>> I understand you "follow the ESP format but feel no shame on >> changing >>>> it if we see a reason to do so", but I am (shamelessly ;) wondering >>>> about the actual reason to do so, as per one of the famous >>>> Architectural Principles of the Internet documented in RFC 1958: >>>>=20 >>>> 3.2 If there are several ways of doing the same thing, choose one. >>>> If a previous design, in the Internet context or elsewhere, has >>>> successfully solved the same problem, choose the same solution >> unless >>>> there is a good technical reason not to. Duplication of the same >>>> protocol functionality should be avoided as far as possible, >> without >>>> of course using this argument to reject improvements. >>>>=20 >>>> Would you mind enlightening us? >>>>=20 >>>> --julien >>>>=20 >>>> jouni korhonen wrote: >>>>>=20 >>>>> Few things. The draft already states that "The Padding, Pad = Length, >>>>> Next Header and ICV fields follow the rules of Section 2.4 to 2.8 >> of >>>>> [RFC4303] unless otherwise stated in this document." So, we follow >>>>> the ESP format but feel no shame on changing it if we see a reason >>>>> to do so. >>>>>=20 >>>>> The reason why we chose to do it like this was two fold: 1) some >>>>> ciphers etc when used would need ~equivalent encapsulation anyway. >>>>> 2) if we had come up with our very own format the question on the >>>>> list would have been "why not using RFC4303 encapsulation format". >>>>> Actually.. the latter already happened offline. >>>>>=20 >>>>> - Jouni >>>>>=20 >>>>>=20 >>>>> On Jan 26, 2011, at 12:48 AM, Laganier, Julien wrote: >>>>>=20 >>>>>> Hi Raj, >>>>>>=20 >>>>>>> Inline: >>>>>>>=20 >>>>>>> On 1/24/11 3:58 PM, "ext Arnaud Ebalard" <arno@natisbad.org> >>>> wrote: >>>>>>>=20 >>>>>>>>=20 >>>>>>>> To me, what the draft describes is a patchwork based on MIPv6, >>>> ESP >>>>> and >>>>>>>> TLS. Instead of building on top of those protocols (read >>>> modularity >>>>>>> and >>>>>>>> interoperability), it reuses (hijacks) various blocks of >>>> associated >>>>>>>> standards in a non-modular way. For instance, one has to >>>>> reimplement >>>>>>> ESP >>>>>>>> in userspace to support the protocol. >>>>>>>=20 >>>>>>> We are specifying an encapsulation method in the I-D. To say = that >>>>> one >>>>>>> has to reimplement ESP in userspace is incorrect. >>>>>>=20 >>>>>> The encapsulation format you have in the I-D is: >>>>>>=20 >>>>>> 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 >>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>>> | | >>>>>> : IPv4 or IPv6 header (src-addr=3DXa, dst-addr=3DYa) = : >>>>>> | | >>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>>> | | >>>>>> : UDP header (src-port=3DXp,dst-port=3DYp) = : >>>>>> | | >>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> - >>>> -- >>>>> --- >>>>>> |PType=3D8| SPI = | >>>>> ^Int. >>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>> |Cov- >>>>>> | Sequence Number | >>>>> |ered >>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | >>>> - >>>>> --- >>>>>> | Payload Data* (variable) | >> | >>>>> ^ >>>>>> : : >> | >>>>> | >>>>>> | | >>>>> |Conf. >>>>>> + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>> |Cov- >>>>>> | | Padding (0-255 bytes) | >>>>> |ered* >>>>>> +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | >>>>> | >>>>>> | | Pad Length | Next Header | >> v >>>>> v >>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> - >>>> -- >>>>> --- >>>>>> | Integrity Check Value-ICV (variable) | >>>>>> : : >>>>>> | | >>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>>>=20 >>>>>> Figure 7: UDP Encapsulated Binding Management Message Format >>>>>>=20 >>>>>> Which looks like a copy/paste of the ESP specification [RFC4303]: >>>>>>=20 >>>>>> 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 >>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> - >>>> -- >>>>> - >>>>>> | Security Parameters Index (SPI) | >>>>> ^Int. >>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>> |Cov- >>>>>> | Sequence Number | >>>>> |ered >>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | >>>> - >>>>> --- >>>>>> | Payload Data* (variable) | >> | >>>>> ^ >>>>>> ~ ~ >> | >>>>> | >>>>>> | | >>>>> |Conf. >>>>>> + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>> |Cov- >>>>>> | | Padding (0-255 bytes) | >>>>> |ered* >>>>>> +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | >>>>> | >>>>>> | | Pad Length | Next Header | >> v >>>>> v >>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> - >>>> -- >>>>> --- >>>>>> | Integrity Check Value-ICV (variable) | >>>>>> ~ ~ >>>>>> | | >>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>>>=20 >>>>>> Figure 1. Top-Level Format of an ESP Packet >>>>>>=20 >>>>>>=20 >>>>>> So the question is: Is your intent to provide a UDP encapsulation >>>>> format for the already specified ESP protocol, or to provide an >>>>> alternative encapsulation format to ESP? >>>>>>=20 >>>>>> --julien >>>>>> _______________________________________________ >>>>>> MEXT mailing list >>>>>> MEXT@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>=20 >>>>> _______________________________________________ >>>>> MEXT mailing list >>>>> MEXT@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mext >>>> _______________________________________________ >>>> MEXT mailing list >>>> MEXT@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mext >=20 From julienl@qualcomm.com Fri Jan 28 15:07:03 2011 Return-Path: <julienl@qualcomm.com> X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A9983A68B7 for <mext@core3.amsl.com>; Fri, 28 Jan 2011 15:07:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.421 X-Spam-Level: X-Spam-Status: No, score=-106.421 tagged_above=-999 required=5 tests=[AWL=0.178, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TW++5sfR9Djx for <mext@core3.amsl.com>; Fri, 28 Jan 2011 15:07:01 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 4B4203A67EC for <mext@ietf.org>; Fri, 28 Jan 2011 15:07:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1296256208; x=1327792208; h=from:to:cc:subject:thread-topic:thread-index:date: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: x-originating-ip:content-type:content-transfer-encoding: mime-version; z=From:=20"Laganier,=20Julien"=20<julienl@qualcomm.com> |To:=20Jouni=20<jouni.nospam@gmail.com>|CC:=20"Basavaraj. Patil@nokia.com"=20<Basavaraj.Patil@nokia.com>,=20"jan@go 6.si"=0D=0A=09<jan@go6.si>,=20"mext@ietf.org"=20<mext@iet f.org>,=20"arno@natisbad.org"=0D=0A=09<arno@natisbad.org> |Subject:=20RE:=20[MEXT]=20Call=20for=20WG=20adoption=20o f=09I-D:=0D=0A=20draft-korhonen-mext-mip6-altsec |Thread-Topic:=20[MEXT]=20Call=20for=20WG=20adoption=20of =09I-D:=0D=0A=20draft-korhonen-mext-mip6-altsec |Thread-Index:=20AQHLvzov3JMqMUYi50SJ29cdxJAzppPm9iVAgACO RYD//31ZIA=3D=3D|Date:=20Fri,=2028=20Jan=202011=2023:10:0 7=20+0000|Message-ID:=20<98A16B2D00B5724F81E80EF1927A0297 040A7F@nasanexd01e.na.qualcomm.com>|References:=20<878vya rmku.fsf@natisbad.org>=0D=0A=20<C963527A.D013%basavaraj.p atil@nokia.com>=0D=0A=20<98A16B2D00B5724F81E80EF1927A0297 03E3FB@nasanexd01e.na.qualcomm.com>=0D=0A=20<06CCEF13-4E1 1-474D-A25E-C1425D5B520A@gmail.com>=0D=0A=20<98A16B2D00B5 724F81E80EF1927A029703EAD4@nasanexd01e.na.qualcomm.com> =0D=0A=20<98A16B2D00B5724F81E80EF1927A02970409A1@nasanexd 01e.na.qualcomm.com>=0D=0A=20<185D5B42-0A88-4CDB-8FFF-B49 FD52D6DD5@gmail.com>=0D=0A=20<98A16B2D00B5724F81E80EF1927 A0297040A1E@nasanexd01e.na.qualcomm.com>=0D=0A=20<B7C8214 5-9053-447A-BB4F-AB17D371BF64@gmail.com>|In-Reply-To:=20< B7C82145-9053-447A-BB4F-AB17D371BF64@gmail.com> |Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|x-originating-ip: =20[172.30.39.5]|Content-Type:=20text/plain=3B=20charset =3D"us-ascii"|Content-Transfer-Encoding:=20quoted-printab le|MIME-Version:=201.0; bh=omDzcAr58uwBkgtHvneYk6OC2Q/Hi3kjLSN7QvLTebc=; b=xQtdfcpgvNgUCvbjOs552TN9hGQDSwMHCs52pKOJyCzmKU1D6lLHbaK6 r4+AU2RBaWoGmfTB5Yd7KR/0PrHDSbXSufonDi3ufFWak0fXjirliIFhq 0WbuXs0gFCFzBgB7yPASWu7eCOA5a4LUJi34hsowfMXHDgy0m4+g0bTQm U=; X-IronPort-AV: E=McAfee;i="5400,1158,6240"; a="72404383" Received: from ironmsg03-r.qualcomm.com ([172.30.46.17]) by wolverine01.qualcomm.com with ESMTP; 28 Jan 2011 15:10:08 -0800 X-IronPort-AV: E=Sophos;i="4.60,392,1291622400"; d="scan'208";a="45548344" Received: from nasanexhc05.na.qualcomm.com ([172.30.48.2]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/AES128-SHA; 28 Jan 2011 15:10:08 -0800 Received: from NASANEXD01E.na.qualcomm.com ([fe80::6555:8c37:4ee3:efc4]) by nasanexhc05.na.qualcomm.com ([::1]) with mapi id 14.01.0218.012; Fri, 28 Jan 2011 15:10:07 -0800 From: "Laganier, Julien" <julienl@qualcomm.com> To: Jouni <jouni.nospam@gmail.com> Thread-Topic: [MEXT] Call for WG adoption of I-D: draft-korhonen-mext-mip6-altsec Thread-Index: AQHLvzov3JMqMUYi50SJ29cdxJAzppPm9iVAgACORYD//31ZIA== Date: Fri, 28 Jan 2011 23:10:07 +0000 Message-ID: <98A16B2D00B5724F81E80EF1927A0297040A7F@nasanexd01e.na.qualcomm.com> References: <878vyarmku.fsf@natisbad.org> <C963527A.D013%basavaraj.patil@nokia.com> <98A16B2D00B5724F81E80EF1927A029703E3FB@nasanexd01e.na.qualcomm.com> <06CCEF13-4E11-474D-A25E-C1425D5B520A@gmail.com> <98A16B2D00B5724F81E80EF1927A029703EAD4@nasanexd01e.na.qualcomm.com> <98A16B2D00B5724F81E80EF1927A02970409A1@nasanexd01e.na.qualcomm.com> <185D5B42-0A88-4CDB-8FFF-B49FD52D6DD5@gmail.com> <98A16B2D00B5724F81E80EF1927A0297040A1E@nasanexd01e.na.qualcomm.com> <B7C82145-9053-447A-BB4F-AB17D371BF64@gmail.com> In-Reply-To: <B7C82145-9053-447A-BB4F-AB17D371BF64@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.30.39.5] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mext@ietf.org" <mext@ietf.org>, "jan@go6.si" <jan@go6.si>, "Basavaraj.Patil@nokia.com" <Basavaraj.Patil@nokia.com> Subject: Re: [MEXT] Call for WG adoption of I-D: draft-korhonen-mext-mip6-altsec X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG <mext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/mext> List-Post: <mailto:mext@ietf.org> List-Help: <mailto:mext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 28 Jan 2011 23:07:03 -0000 None of these two points explains to me why you have to duplicate ESP funct= ionality: 1) You have chosen to handle SPI differently, but I don't know why.=20 2) As to ESP being absent, if the goal is to not protect some of the user-p= lane traffic, you can use ESP-NULL, or just the UDP encap... --julien None of the above explains why you need to=20 Jouni wrote: > =20 > Hmm.. we do handle SPIs differently and our "ESP" can be absent even if > UDP encap is used. Would that be an issue regarding the reuse of > existing formats? >=20 > - Jouni >=20 >=20 > On Jan 29, 2011, at 12:29 AM, Laganier, Julien wrote: >=20 > > Either. > > > > IMHO both would be cleaner that the current approach. I understand > the latter might also have some caveat but maybe they can be dealt with > in an elegant manner, without introducing too much complexity, e.g., > see Arnaud's m6t (http://tools.ietf.org/html/draft-ebalard-mext-m6t- > 02.txt) > > > > --julien > > > > Jouni wrote: > >> > >> Just a question for my clarification. Do you mean simply taking the > UDP > >> encap + ESP format or also inheriting everything those respective > RFCs > >> say about their processing etc? > >> > >> - JOuni > >> > >> > >> On Jan 28, 2011, at 9:18 PM, Laganier, Julien wrote: > >> > >>> Hello again, > >>> > >>> Thought that maybe making my question a bit more specific would > help: > >>> > >>> So, why don't you simply define a UDP encapsulation to ESP, instead > >> of duplicating ESP functionality into your framework? > >>> > >>> --julien > >>> > >>> Laganier, Julien wrote: > >>>> > >>>> Hi Jouni, > >>>> > >>>> I understand you "follow the ESP format but feel no shame on > >> changing > >>>> it if we see a reason to do so", but I am (shamelessly ;) > wondering > >>>> about the actual reason to do so, as per one of the famous > >>>> Architectural Principles of the Internet documented in RFC 1958: > >>>> > >>>> 3.2 If there are several ways of doing the same thing, choose one. > >>>> If a previous design, in the Internet context or elsewhere, has > >>>> successfully solved the same problem, choose the same solution > >> unless > >>>> there is a good technical reason not to. Duplication of the same > >>>> protocol functionality should be avoided as far as possible, > >> without > >>>> of course using this argument to reject improvements. > >>>> > >>>> Would you mind enlightening us? > >>>> > >>>> --julien > >>>> > >>>> jouni korhonen wrote: > >>>>> > >>>>> Few things. The draft already states that "The Padding, Pad > Length, > >>>>> Next Header and ICV fields follow the rules of Section 2.4 to 2.8 > >> of > >>>>> [RFC4303] unless otherwise stated in this document." So, we > follow > >>>>> the ESP format but feel no shame on changing it if we see a > reason > >>>>> to do so. > >>>>> > >>>>> The reason why we chose to do it like this was two fold: 1) some > >>>>> ciphers etc when used would need ~equivalent encapsulation anyway. > >>>>> 2) if we had come up with our very own format the question on the > >>>>> list would have been "why not using RFC4303 encapsulation format". > >>>>> Actually.. the latter already happened offline. > >>>>> > >>>>> - Jouni > >>>>> > >>>>> > >>>>> On Jan 26, 2011, at 12:48 AM, Laganier, Julien wrote: > >>>>> > >>>>>> Hi Raj, > >>>>>> > >>>>>>> Inline: > >>>>>>> > >>>>>>> On 1/24/11 3:58 PM, "ext Arnaud Ebalard" <arno@natisbad.org> > >>>> wrote: > >>>>>>> > >>>>>>>> > >>>>>>>> To me, what the draft describes is a patchwork based on MIPv6, > >>>> ESP > >>>>> and > >>>>>>>> TLS. Instead of building on top of those protocols (read > >>>> modularity > >>>>>>> and > >>>>>>>> interoperability), it reuses (hijacks) various blocks of > >>>> associated > >>>>>>>> standards in a non-modular way. For instance, one has to > >>>>> reimplement > >>>>>>> ESP > >>>>>>>> in userspace to support the protocol. > >>>>>>> > >>>>>>> We are specifying an encapsulation method in the I-D. To say > that > >>>>> one > >>>>>>> has to reimplement ESP in userspace is incorrect. > >>>>>> > >>>>>> The encapsulation format you have in the I-D is: > >>>>>> > >>>>>> 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 > >>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > + > >>>>>> | > | > >>>>>> : IPv4 or IPv6 header (src-addr=3DXa, dst- > addr=3DYa) : > >>>>>> | > | > >>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > + > >>>>>> | > | > >>>>>> : UDP header (src-port=3DXp,dst- > port=3DYp) : > >>>>>> | > | > >>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > + > >> - > >>>> -- > >>>>> --- > >>>>>> |PType=3D8| SPI > | > >>>>> ^Int. > >>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > + > >>>>> |Cov- > >>>>>> | Sequence Number > | > >>>>> |ered > >>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > + > >> | > >>>> - > >>>>> --- > >>>>>> | Payload Data* (variable) > | > >> | > >>>>> ^ > >>>>>> : > : > >> | > >>>>> | > >>>>>> | > | > >>>>> |Conf. > >>>>>> + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > + > >>>>> |Cov- > >>>>>> | | Padding (0-255 bytes) > | > >>>>> |ered* > >>>>>> +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > + > >> | > >>>>> | > >>>>>> | | Pad Length | Next Header > | > >> v > >>>>> v > >>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > + > >> - > >>>> -- > >>>>> --- > >>>>>> | Integrity Check Value-ICV (variable) > | > >>>>>> : > : > >>>>>> | > | > >>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > + > >>>>>> > >>>>>> Figure 7: UDP Encapsulated Binding Management Message Format > >>>>>> > >>>>>> Which looks like a copy/paste of the ESP specification > [RFC4303]: > >>>>>> > >>>>>> 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 > >>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > + > >> - > >>>> -- > >>>>> - > >>>>>> | Security Parameters Index (SPI) > | > >>>>> ^Int. > >>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > + > >>>>> |Cov- > >>>>>> | Sequence Number > | > >>>>> |ered > >>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > + > >> | > >>>> - > >>>>> --- > >>>>>> | Payload Data* (variable) > | > >> | > >>>>> ^ > >>>>>> ~ > ~ > >> | > >>>>> | > >>>>>> | > | > >>>>> |Conf. > >>>>>> + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > + > >>>>> |Cov- > >>>>>> | | Padding (0-255 bytes) > | > >>>>> |ered* > >>>>>> +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > + > >> | > >>>>> | > >>>>>> | | Pad Length | Next Header > | > >> v > >>>>> v > >>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > + > >> - > >>>> -- > >>>>> --- > >>>>>> | Integrity Check Value-ICV (variable) > | > >>>>>> ~ > ~ > >>>>>> | > | > >>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > + > >>>>>> > >>>>>> Figure 1. Top-Level Format of an ESP Packet > >>>>>> > >>>>>> > >>>>>> So the question is: Is your intent to provide a UDP > encapsulation > >>>>> format for the already specified ESP protocol, or to provide an > >>>>> alternative encapsulation format to ESP? > >>>>>> > >>>>>> --julien > >>>>>> _______________________________________________ > >>>>>> MEXT mailing list > >>>>>> MEXT@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/mext > >>>>> > >>>>> _______________________________________________ > >>>>> MEXT mailing list > >>>>> MEXT@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/mext > >>>> _______________________________________________ > >>>> MEXT mailing list > >>>> MEXT@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/mext > > From Fred.L.Templin@boeing.com Fri Jan 28 15:28:11 2011 Return-Path: <Fred.L.Templin@boeing.com> X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 575743A6954 for <mext@core3.amsl.com>; Fri, 28 Jan 2011 15:28:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.47 X-Spam-Level: X-Spam-Status: No, score=-6.47 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u5whnJZ9nZfQ for <mext@core3.amsl.com>; Fri, 28 Jan 2011 15:28:10 -0800 (PST) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by core3.amsl.com (Postfix) with ESMTP id 18E043A68A8 for <mext@ietf.org>; Fri, 28 Jan 2011 15:28:10 -0800 (PST) Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by slb-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p0SNVD76023109 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <mext@ietf.org>; Fri, 28 Jan 2011 15:31:13 -0800 (PST) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id p0SNVC1r003127 for <mext@ietf.org>; Fri, 28 Jan 2011 15:31:13 -0800 (PST) Received: from XCH-NWHT-11.nw.nos.boeing.com (xch-nwht-11.nw.nos.boeing.com [130.247.25.114]) by slb-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p0SNVC4D003109 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK) for <mext@ietf.org>; Fri, 28 Jan 2011 15:31:12 -0800 (PST) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-11.nw.nos.boeing.com ([130.247.25.114]) with mapi; Fri, 28 Jan 2011 15:31:12 -0800 From: "Templin, Fred L" <Fred.L.Templin@boeing.com> To: "mext@ietf.org" <mext@ietf.org> Date: Fri, 28 Jan 2011 15:31:10 -0800 Thread-Topic: IRON - a new approach to mobility management Thread-Index: Acu9ZObUeEtp4wpfT9m3W4BGslqdFwAIrYJQADbmZMAAN/RKAA== Message-ID: <E1829B60731D1740BB7A0626B4FAF0A65C68283EAF@XCH-NW-01V.nw.nos.boeing.com> References: <AANLkTikGBOTOopf5g0SVvSe1-f1fBK38CN+mSnPdp+8D@mail.gmail.com><E 1829B60731D1740BB7A0626B4FAF0A65C682836E4@XCH-NW-01V.nw.nos.boeing.com> <E1829B60731D1740BB7A0626B4FAF0A65C68283AB4@XCH-NW-01V.nw.nos.boeing.com> In-Reply-To: <E1829B60731D1740BB7A0626B4FAF0A65C68283AB4@XCH-NW-01V.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [MEXT] IRON - a new approach to mobility management X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG <mext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/mext> List-Post: <mailto:mext@ietf.org> List-Help: <mailto:mext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 28 Jan 2011 23:28:11 -0000 I should also mention that an initial implementation is available: http://www.ietf.org/mail-archive/web/int-area/current/msg02471.html http://www.ietf.org/mail-archive/web/int-area/current/msg02472.html Thanks - Fred fred.l.templin@boeing.com=20 > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On=20 > Behalf Of Templin, Fred L > Sent: Thursday, January 27, 2011 1:01 PM > To: mext@ietf.org > Subject: Re: [MEXT] IRON - a new approach to mobility management >=20 > Here is another aspect of the proposal that should be > of interest to this community: >=20 > http://www.ietf.org/id/draft-templin-ironmike-00.txt >=20 > This shows how the IRON approach aligns with MOBIKE to > present a system for managing VPN links that allows > clients to connect to a nearby VPN gateway that in turn > connects to a trusted and secure network. As clients > change ISP connections, the VPN gateways naturally learn > about the changes. As clients move significant distances, > they simply discover and connect to a different nearby VPN > gateway. Client-to-client communications then are conveyed > across the trusted and secure network. Very simple; very > few moving parts. >=20 > Fred > fred.l.templin@boeing.com=20 >=20 > > -----Original Message----- > > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On=20 > > Behalf Of Templin, Fred L > > Sent: Wednesday, January 26, 2011 1:27 PM > > To: mext@ietf.org > > Subject: [MEXT] IRON - a new approach to mobility management > >=20 > > Hello, > >=20 > > I would like to introduce a new approach to mobility > > management, which is an in-built feature of a new > > routing and addressing system known as the Internet > > Routing Overlay Network (IRON): > >=20 > > http://www.rfc-editor.org/internet-drafts/draft-templin-iron-17.txt > >=20 > > IRON is a product of the IRTF Routing Research Group > > (RRG), which was chartered to provide recommendations > > on addressing the Internet routing scaling issue. While > > the IRON development effort focused primarily on routing > > scaling, it soon became clear that mobility management > > was also naturally afforded by the base architecture > > with no need for adjunct mechanisms. Also, although this > > fully-integrated proposal is new many of the concepts were > > motivated by earlier works. The document therefore cites > > related initiatives which explored similar concepts. > >=20 > > The IRON mobility management approach combines the best > > aspects of both proactive and on-demand route discovery. > > IRON Clients (which may include mobile end systems and > > mobile routers) discover topologically-close IRON Serving > > routers (i.e., "Servers") and create a connection with > > one of the Servers for the purpose of maintaining=20 > > bidirectional tunnel neighbor state. The Client then > > registers one or more of its interfaces with the Server > > so that the Server has handles for sending return traffic > > to the Client. Since the Server can observe the public-side > > address(es) of the Client without the Client needing to > > discover them itself, the system therefore also naturally > > supports a simplified form of NAT traversal.=20 > >=20 > > When a Client connects to the Server, the Server sends a > > "link up" indication via a dynamic routing update that is > > propagated to a core set of Relay routers (i.e., "Relays"). > > In practice, there will be O(10's) of Relays while there > > may be several orders of magnitude more Servers that are > > topologically distributed throughout the Internet. Only > > the Relays need maintain a full topology in their routing > > tables; Servers need only maintain routing table entries > > for their current set of connected Clients. > >=20 > > When a Client 'A' connected to Server 'Y' has a packet to > > send to a new correspondent Client 'B' connected to Server > > 'Z', 'A' first tunnels the packet to 'Y' as its default > > router in the overlay network. Since 'Y' has only partial > > topology information, it then tunnels the packet to a Relay > > 'R'. Since 'R' has full topology knowledge, it then tunnels > > the packet to 'Z' which in turn tunnels the packet to 'B'. > > At the same time, 'Z' also returns a Redirect message to > > inform 'Y' that 'Z' is a better next hop in the overlay > > network to reach 'B'. If 'Y' is configured to forward > > Redirects to its Clients, it then forwards the Redirect to > > 'A' which then populates its routing tables with a more- > > specific route. Otherwise, 'Y' uses the Redirect to update > > its own routing tables. Hence, route optimization is > > naturally supported. > >=20 > > When 'A' changes its ISP points of attachement (i.e., when > > 'A' moves), it need not explicitly inform 'Y' of the changes > > as long as it wishes to retain 'Y' as its Server, since 'Y' > > will naturally discover any changes in 'A''s address(es) via > > the source addresses of 'A''s packets. 'A' also need not > > inform any of its recent correspondents about the changes, > > since the correspondents can still reach 'A' via 'Y'. Hence, > > localized mobility events are communicated implicitly and > > immediately with no need for binding updates. > >=20 > > When 'A' moves far away from 'Y', it can leisurely discover > > a new nearby Server 'W'. It can then connect to 'W' and > > disconnect from 'Y' which will cause dynamic routing between > > the overlay network Relays to naturally update 'A''s > > Client-to-Server bindings. Hence, routing stretch is > > managed without need for delay-sensitive actions. > >=20 > > Finally, the base system does not require Client-to-Client > > binding updates. For example, if Client 'C' has a routing > > table for 'A' with next-hop 'Y', but 'A' has moved to a > > new Server 'W', 'C' will receive Redirect messages from > > 'Y' informing it that 'A' is now associated with 'W'. > > Hence, 'A' need not keep track of recent correspondents, > > since any correspondents will naturally be redirected to > > 'A's new location without risk of packet loss. (Again, > > this is a coarse-grained mobility consideration, since > > 'A' will typically not change to a new Server unless it > > moves some significant distance, e.g., 1000 miles). > >=20 > > Comments and questions welcome, > >=20 > > Fred > > fred.l.etmplin@boeing.com > > _______________________________________________ > > MEXT mailing list > > MEXT@ietf.org > > https://www.ietf.org/mailman/listinfo/mext > >=20 > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > = From maxpassion@gmail.com Sun Jan 30 16:30:59 2011 Return-Path: <maxpassion@gmail.com> X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B5563A68EA for <mext@core3.amsl.com>; Sun, 30 Jan 2011 16:30:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.727 X-Spam-Level: X-Spam-Status: No, score=-2.727 tagged_above=-999 required=5 tests=[AWL=0.872, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HStlbd+ASTEu for <mext@core3.amsl.com>; Sun, 30 Jan 2011 16:30:58 -0800 (PST) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id 16D963A68BF for <mext@ietf.org>; Sun, 30 Jan 2011 16:30:58 -0800 (PST) Received: by qyj19 with SMTP id 19so5193886qyj.10 for <mext@ietf.org>; Sun, 30 Jan 2011 16:34:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=QTyoo0O0q09LWMx2+fqeErdvkv1g9W/+UMSCbO6tTHY=; b=C8Zzqjtuqf5EH7AXEThRRadtdwNsgF3U6PU50J5b7deJUtaJpFbZEJH25Q4Z5zv59P lfyuSR1hoLlkfzxdiK7PcYjMJF7wIxRWiCWR2TzQ0Gp0F0zzuG0umONIRRym2xu3HDn6 3m6PsTvnyfTABCG0tBO19MX2jZnKrGshjg/fA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=TeAFOeAVRbHv1BPLRdqNKTUovbt9RWyuKCiefnwuZX59/ZLvWOvew5WZxqVRHh91l9 54DpoIuMDsXxpWBmVHogGNEHJxHhiCsbCNELpbp1zxcWltQw2yRAMnd5Slk0CsFAA//9 5a9/DXgqAxReCjhMLxwI/u9p31XcOEcAg5yQ0= MIME-Version: 1.0 Received: by 10.224.80.210 with SMTP id u18mr5844724qak.122.1296434049206; Sun, 30 Jan 2011 16:34:09 -0800 (PST) Received: by 10.220.65.152 with HTTP; Sun, 30 Jan 2011 16:34:08 -0800 (PST) In-Reply-To: <4D3DD426.6080107@it.uc3m.es> References: <4D3DD426.6080107@it.uc3m.es> Date: Mon, 31 Jan 2011 08:34:08 +0800 Message-ID: <AANLkTinDOq75vdPfkCWJKN9j8hYjj8vEjFERukuYEfFy@mail.gmail.com> From: liu dapeng <maxpassion@gmail.com> To: marcelo bagnulo braun <marcelo@it.uc3m.es> Content-Type: text/plain; charset=ISO-8859-1 Cc: mext <mext@ietf.org> Subject: Re: [MEXT] Call for WG adoption of I-D: draft-korhonen-mext-mip6-altsec X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG <mext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/mext> List-Post: <mailto:mext@ietf.org> List-Help: <mailto:mext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 31 Jan 2011 00:30:59 -0000 Hi all, I support this I-D being adopted as WG document. It is useful to simplify the deployment of MIPv6/DSMIPv6. I also have the chance to test the implementation on mobile phone, it works fine. Thanks. Regards, Dapeng Liu 2011/1/25, marcelo bagnulo braun <marcelo@it.uc3m.es>: > The ID has had 3 reviews as we require. > So, we are now ready to ask the WG if they think we should adopt the > document. > > Please express your opinion before monday 31st jan. > > Reviews can be found: > > The I-D: draft-korhonen-mext-mip6-altsec-06 has been reviewed by: > > 1. Jan Zorz > http://www.ietf.org/mail-archive/web/mext/current/msg04489.html > > 2. Domagoz Premec > http://www.ietf.org/mail-archive/web/mext/current/msg04457.html > > 3. Ryuji Wakikawa > http://www.ietf.org/mail-archive/web/mext/current/msg04470.html > > > > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > From georg.hampel@alcatel-lucent.com Mon Jan 31 07:15:06 2011 Return-Path: <georg.hampel@alcatel-lucent.com> X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E62D33A6B32 for <mext@core3.amsl.com>; Mon, 31 Jan 2011 07:15:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.585 X-Spam-Level: X-Spam-Status: No, score=-6.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ZfGL2b9Tvt7 for <mext@core3.amsl.com>; Mon, 31 Jan 2011 07:15:05 -0800 (PST) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by core3.amsl.com (Postfix) with ESMTP id D2C203A6AC9 for <mext@ietf.org>; Mon, 31 Jan 2011 07:15:04 -0800 (PST) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id p0VFIImc016254 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <mext@ietf.org>; Mon, 31 Jan 2011 09:18:18 -0600 (CST) Received: from USNAVSXCHHUB03.ndc.alcatel-lucent.com (usnavsxchhub03.ndc.alcatel-lucent.com [135.3.39.112]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p0VFIIaE012376 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for <mext@ietf.org>; Mon, 31 Jan 2011 09:18:18 -0600 Received: from USNAVSXCHMBSA2.ndc.alcatel-lucent.com ([135.3.39.127]) by USNAVSXCHHUB03.ndc.alcatel-lucent.com ([135.3.39.112]) with mapi; Mon, 31 Jan 2011 09:18:18 -0600 From: "Hampel, K Georg (K Georg)" <georg.hampel@alcatel-lucent.com> To: "Hampel, K Georg (K Georg)" <georg.hampel@alcatel-lucent.com>, "mext@ietf.org" <mext@ietf.org> Date: Mon, 31 Jan 2011 09:18:16 -0600 Thread-Topic: [MEXT] Support of route optimization in *absence* of HA Thread-Index: AQHLvLj8UEf1urDUyUWHHSacIaQ4WJPjE1YFgACCiCCAB6KDwA== Message-ID: <154773479ED2314980CB638A48FC44348341D219@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> References: <154773479ED2314980CB638A48FC44348334CE4F@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <98A16B2D00B5724F81E80EF1927A0297036BB6@nasanexd01e.na.qualcomm.com> <154773479ED2314980CB638A48FC44348334CFA1@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <98A16B2D00B5724F81E80EF1927A029703A7F6@nasanexd01e.na.qualcomm.com> <154773479ED2314980CB638A48FC44348334D271@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <98A16B2D00B5724F81E80EF1927A029703CA27@nasanexd01e.na.qualcomm.com> <154773479ED2314980CB638A48FC4434833B9F67@USNAVSXCHMBSA2.ndc.alcatel-lucent.com>, <31821_1295978112_4D3F0E80_31821_2069_1_4D3F0E74.5020403@gmail.com> <64FACAB831EEEB418F27A18FE09095243CF932C6@EXMDB08.org.aalto.fi> <154773479ED2314980CB638A48FC4434833BA59E@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> In-Reply-To: <154773479ED2314980CB638A48FC4434833BA59E@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Subject: Re: [MEXT] Support of route optimization in *absence* of HA X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG <mext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/mext> List-Post: <mailto:mext@ietf.org> List-Help: <mailto:mext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 31 Jan 2011 15:15:07 -0000 Hi All, One more comment on HA-free operation: Multi-homed hosts, e.g. smart phones with WLAN and 3G/4G interface, can per= form HA-free handover between both networks using the straightforward RR pr= ocedure of RFC 3775. Since both paths are simultaneously supported, MN is a= lways at home and HoT/HoTi can be supported in parallel to CoT/CoTi. In this case, 3GPP-mobility runs underneath MIPv6 and would appear as a loc= al mobility protocol confined to the 3GPP network. - Georg -----Original Message----- From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of Ham= pel, K Georg (K Georg) Sent: Wednesday, January 26, 2011 2:04 PM To: M=E4kel=E4 Antti; Alexandru Petrescu; mext@ietf.org Subject: Re: [MEXT] Support of route optimization in *absence* of HA Hi Antti, It would make sense to quantify your concerns about persistent connections = that "borrow" IP addresses from foreign networks for extended time. I don't= see a problem if the "HoA" is only used by upper layers, i.e. when the MN = has already moved to another netowrk. DHCPv6 lease expiry may be a problem = when the MN stays in the foreign network for an extended period of time and= the lease cannot be renewed (Stateless address autoconfiguration should no= t encounter this problem ?!.:) HA-free RO has other limits: - Simultaneous movment of both end points cannot be supported in break-befo= re-make manner. - Applications that cache and reuse IP addreses after some time run into tr= ouble if mobility events have occurred in between. - Mobile servers require support of dynamic location service. I think HA-free RO should be considered an option which provides net benefi= ts for a large fraction of traffic. It does not have to cover *all* situati= ons. I think it is important to identify potential vulnerabilities. In most= cases, however, the worst that can happen is that the conenction breaks. - Georg -----Original Message----- From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of M= =E4kel=E4 Antti Sent: Wednesday, January 26, 2011 6:22 AM To: Alexandru Petrescu; mext@ietf.org Subject: Re: [MEXT] Support of route optimization in *absence* of HA Hi, HA-less RO sounds like a very interesting effort. The resemblances to ad-= hoc routing are quite large though. From how I understood the draft, the us= e case and primary scenario is the situation where the mobile node has most= ly outbound traffic, and simply needs to make sure that sessions don't get = interrupted if the node moves. I agree that security should probably be made "modular" in the sense that= you are free to secure the RO with any way you choose, or even without any= security at all (in a trusted environment). In essence the current suggestion sounds like: Mobile Node chooses a "HoA" from one of the current interface addresses a= nd acts as it's in "home network" Starts communicating with CN If node moves, tell the CN via RO procedure that me, previously at home, = now have a CoA that corresponds to my HoA Any new sessions should use the new network's address as "HoA", and if th= e session to the CN ends, the RO should be torn down as well. My primary concerns with this basic idea are related to persistent sessio= ns - some application connecting to the CN and keeping the same connection,= so the MN can never relinquish the HoA. This leads to the philosophical is= sue about if you are a mobile node and using such "ad-hoc" HoAs that you ha= ve picked up on the way, do you have the permission to make such address mo= bile (take it out of the network)? In an environment with HA, the HA gives you explicit permission that yes,= you can use this address, from my network, owned by me, to communicate wit= h rest of the world. Without HA, considering whatever network you happen to be in when first c= ommunicating to a CN your "home network" - should the MN be allowed to move= the HoA away? For how long? Until DHCPv6 lease expires? Until RA timer expires? When? -- - Antti M=E4kel=E4 | Researcher - - Department of communications and networking - - Aalto University - ________________________________________ From: mext-bounces@ietf.org [mext-bounces@ietf.org] on behalf of Alexandru = Petrescu [alexandru.petrescu@gmail.com] Sent: Tuesday, January 25, 2011 19:55 To: mext@ietf.org Subject: Re: [MEXT] Support of route optimization in *absence* of HA Thanks for listing these 3 documents. For what it's worth... I think it would be good to decouple the security effort from the HA-less part of the effort. I would thus go further with the proposal to operate on a more general level. Do you have anything against a basic RO HA-less which is security-less as well? If against, then it would make sense to talk _Secure_ HA-less RO RR. If for, then it would make sense to cite http://tools.ietf.org/html/draft-petrescu-autoconf-ra-based-routing-00 and MNPP draft along the 3 documents you cited. I think a basic RO HA-less which is independent of the security mechanism could become a place for adding more security later. For example: add a widely deployed certificate-based https security which secures a link layer (and not CGA, not Mobile IP RR tests). I think that if one tries to further develop existing Mobile IP security mechanisms (CGA, IKE, RR tests) then the goal should be stated in the title, call the effort a security effort, and not simply RO, nor simply RR. For example: return routability tests (called RR in Mobile IP only) exists in other protocols as well (TCP) yet they're not as highly secure as in Mobile IPv6 (nonces, keys). In this sense, in Mobile IP, RR is actually a security effort. RO of Mobile IP does not exist without RR, hence RO is also a security effort. However, it is possible to achieve optimal paths ("route optimization"), without using security. For example, most paths in the Internet are highly optimal in terms of path length, yet very few of them are established securely. I think Mobile IP needs means to offer optimal paths CN-MH (move HA out of the path). However, the effort of offering these paths is not necessarily a security effort. Alex Le 25/01/2011 16:44, Hampel, K Georg (K Georg) a =E9crit : > All, > > Based on feedback and further thoughts, I propose to permit HA-free > operation on a more general level, i.e. for ALL R/O-solutions that > permit return-routability procedure WITHOUT participation of the HA. > Among those are currently: > > - RFC 4866: Enhanced R/O for MIPv6 > > - RFC 4449: Securing MIPv6 R/O using static shared key > > - draft-ebalard-mext-ipsec-ro-01: Mobile IPv6 IPsec Route > Optimization (IRO) > > Note that HA-free R/O was already anticipated by RFC 4651 (A > Taxonomy and Analysis of Enhancements to Mobile IPv6 Route > Optimization). I think it would add substantial value to MIPv6. RFC > 4651 says: > > > > 2.4. Robustness Enhancements > > > > Route Optimization could conceptually enable continued > communications > > during periods of temporary home-agent unavailability. The > protocol > > defined in RFC 3775 does not achieve this independence, however, as > > the home agent plays an active role in the return-routability > > procedure. Appropriate enhancements could increase the > independence > > from the home agent and thus enable robust Route Optimization even > in > > the absence of the home agent. > > Regards, > > - Georg > > ------------------------------------------------------------------------ > > > *From:*Laganier, Julien [mailto:julienl@qualcomm.com] *Sent:* > Saturday, January 22, 2011 1:47 AM *To:* Hampel, K Georg (K Georg); > mext@ietf.org *Cc:* Klein, Thierry E (Thierry) *Subject:* RE: > Support of route optimization in *absence* of HA > > Georg, > > Regarding #1 I haven't decided yet I would like the group to discuss > more. The authorization of the MN to use a given HA could be asserted > in a couple of different ways, including but not limited to, a) the > HA only allows creation of initial binding for on-(home)-link MN, b) > the HA only allows creation of initial bindings for on-site MNs, > i.e., CoA in a provider prefix block, and c) the HA has access to a > list of CGA public keys that are authorized to create bindings. > > Regarding #2, if I am not mistaken, at least the 3GPP Evolved Packet > System mandates stateless address autoconfiguration for global > addresses. Only the link-local address is generated from the IID > sent by the GW. > > Best, > > --julien > > *From:*Hampel, K Georg (K Georg) > [mailto:georg.hampel@alcatel-lucent.com] *Sent:* Friday, January 21, > 2011 11:22 AM *To:* Laganier, Julien; Hampel, K Georg (K Georg); > mext@ietf.org *Cc:* Klein, Thierry E (Thierry) *Subject:* RE: > Support of route optimization in *absence* of HA > > Julien, > > Thanks for the info. I like your proposal. CGA provides > cryptographic security without need for trust-relationships, PKI, > pre-shared keys, etc. > > 1) When IPsec is replaced by CGA, MN only proves the authenticity of > its HoA to the HA. It does not authenticate itself in absolute > terms, i.e. via means of strong authentication as required by IPsec > or TLS. How would the HA know that this MN is authorized to use the > HA's services? > > 2) Do we have any idea to what extend stateless addressing is > "supported"? Does (or will) 3GPP allow stateless addressing? > > -Georg > > ------------------------------------------------------------------------ > > > *From:*Laganier, Julien [mailto:julienl@qualcomm.com] *Sent:* > Friday, January 21, 2011 1:06 PM *To:* Hampel, K Georg (K Georg); > mext@ietf.org *Cc:* Klein, Thierry E (Thierry) *Subject:* RE: > Support of route optimization in *absence* of HA > > Georg, > > Thanks for clarifying, this is what I thought. FWIW, I've tried to > extend the RFC 4866 to secure bindings between the MN and the HA in > http://tools.ietf.org/html/draft-laganier-mext-cga-01 > > --julien > > *From:*Hampel, K Georg (K Georg) > [mailto:georg.hampel@alcatel-lucent.com] *Sent:* Thursday, January > 20, 2011 5:25 PM *To:* Laganier, Julien; mext@ietf.org *Cc:* Klein, > Thierry E (Thierry) *Subject:* RE: Support of route optimization in > *absence* of HA > > Julien, > > The intentions of Homeless MIPv6 are similar to those of our > proposal. > > In contrast to Homeless MIPv6, our proposal requires only minimal > upgrades to the present standard and implementation. (Homeless MIPv6 > requires changes to the TCP/UDP and requires AH, for instance). > > Here's the core idea of HA-free R/O: > > 1)When starting a session, the MN self-declares its current IP > address as the "HoA" for this session. This automatically means that > it resides in its "home network" and can conduct the home test > directly with CN, i.e. no home registration required. > > 2)All further BU/BA signaling is done directly with CN according to > RFC 4866. > > 3)All further signaling with HA is simply omitted. > > Our proposal builds on "enhanced route optimization" (RFC 4866), > which provides a nice security solution for R/O and creates the > ground for HA-free operation. > > Little changes are required: e.g. MN must be able to deregister its > HoA at CN, etc. > > Regards, > > Georg > > ------------------------------------------------------------------------ > > > *From:*Laganier, Julien [mailto:julienl@qualcomm.com] *Sent:* > Thursday, January 20, 2011 4:27 PM *To:* Hampel, K Georg (K Georg); > mext@ietf.org *Cc:* Klein, Thierry E (Thierry) *Subject:* RE: > Support of route optimization in *absence* of HA > > Georg, > > Is it correct that functionally your proposal is similar to Homeless > Mobile IPv6: > > http://tools.ietf.org/html/draft-nikander-mobileip-homelessv6-01 > > Best, > > --julien > > *From:*mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] *On > Behalf Of *Hampel, K Georg (K Georg) *Sent:* Thursday, January 20, > 2011 12:07 PM *To:* mext@ietf.org *Cc:* Hampel, K Georg (K Georg); > Klein, Thierry E (Thierry) *Subject:* [MEXT] Support of route > optimization in *absence* of HA > > All, > > We would like to add a proposal to MEXT that permits the mobile to > engage into route-optimization in *absence* of a home agent. > > Such a feature adds robustness to route optimization in case the HA > is temporarily unavailable. Under some circumstances, route > optimization *without* HA may be beneficial for performance reasons. > Our proposal requires "enhanced route optimization for Mobile IPv6" > (RFC 4866) as pre-requisite. > > We would like to obtain some feedback from the MEXT community via > this mailing list before we submit the proposal as a draft to the > workgroup. For this purpose, we have enclosed a high-level outline > below. Thanks. > > Regards, > > Georg Hampel > > Networking & Networks Domain > > BellLaboratories > > Alcatel-Lucent > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > Proposal: Support of Route-Optimization in Absence of Home Agent > > ABSTRACT: > > The proposal allows the mobile to engage into route optimization > (R/O) in *absence* of a HA. This feature increases robustness when > the HA becomes temporarily unavailable. Under some circumstances, > R/O *without* HA may be beneficial for performance reasons. This > proposal requires "enhanced route optimization for Mobile IPv6" (RFC > 4866) as pre-requisite. > > MOTIVATION: > > In route optimization (R/O), traffic packets are directly exchanged > between hosts without passing the HA. The mobile, however, still has > to interact with the HA. The HA provides (1) location service, (2) a > fallback path in case the direct path breaks, (3) a fallback in case > the correspondent does not support the protocol and (4) security > support for R/O-related signaling (i.e. home test). These functions > come at the following cost: > > =B7Handovers may fail when the link to the HA or the HA itself are > down or congested. Mobility is not supported, when the mobile does > not have a HA. > > =B7When the mobile starts a session outside of its home network, it > must use a HoA pertaining to its home network even if it engages > into R/O. This requirement adds air-interface overhead due to > mobility headers and processing overhead on the mobile. This upfront > cost incurs even if the mobile does not move during the session. > > =B7Signaling handshakes have to be conducted between mobile and HA at > every mobility event. > > Currently, the Mobile IPv6 standard family forces the mobile to bear > these disadvantages in R/O even if the HA functions are not needed. > This specifically applies to scenarios where: > > =B7Traffic is based on mobile-initiated requests to public servers > (majority of present mobile internet traffic). The HA's location > service is not needed for such traffic. Location service may also be > provided by other means such as Dynamic DNS or on application layer > (e.g. SIP registrar). > > =B7The fallback path through the HA has little value when it shares > the weakest link with the direct path. Since the weakest link is > typically the wireless link, this situation applies to all scenarios > where only one air interface is available (this is the typical case > rather than the exception). > > =B7The mobile may know about the correspondent's Mobile-IPv6 support > from prior sessions or through means external to the standard. > > =B7The mobile applies the CGA-based procedure of RFC 4866, which makes > the HA's security support for R/O unnecessary. This applies to all > cases where stateless addressing is permitted. > > To increase the flexibility and robustness of route-optimized Mobile > IPv6, we propose to make the HA an *optional* rather than a > *mandatory* feature, i.e. to permit operation without HA. This > proposal requires some additional extensions to the present > standard. > > HIGH-LEVEL OUTLINE > > The extensions build on Enhanced Route Optimization for Mobile IPv6 > (RFC 4866) to guarantee sufficient signaling security. With the > absence of a HA, mobility support in R/O can be provided in the > following manner: > > =B7The mobile starts the traffic session from any of its currently > supported IP addresses. The selected IP address automatically takes > the function of the HoA for this session. This has the advantage > that conventional transport is used as long as the mobile does not > move, i.e. mobility headers and CoA-vs-HoA mapping is not needed. The > HoA must have been generated via CGA in compliance with RFC 4866. > > =B7The mobile must conduct a "home-test" from this HoA in compliance > with RFC 4866. It may conduct the home-test prior to session > establishment, e.g. to find out if the correspondent supports the > standard. > > =B7All binding update handshakes are conducted on the direct path > according to RFC 4866. > > =B7Since sessions are always started from a currently supported IP > address, temporally overlapping sessions may use different HoAs. A > multi-homed mobile may also decide to start sessions from different > simultaneously supported IP addresses. There is no principle problem > here. > > =B7Opposed to RFC 4866, the mobile need not perform the CoA > registration with the HA. > > =B7The mobile must be able to deregister the HoA at the correspondent > in case the HoA is not supported anymore. This ensures that the > correspondent does not send packets to the HoA. After deregistration > of the HoA, the HoA is still used by higher protocol layers of > ongoing sessions. It must still be included in the mobility headers > for these sessions. > > =B7When the mobile has HA support and the HA becomes temporarily > unavailable, the mobile simply continues R/O without HA as outlined > in the prior points. > > =B7The mobile can publish its IP address in any location service. This > allows other hosts to initiate sessions with the mobile. These > sessions enjoy route-optimized mobility support only if the > published IP address was generated via CGA in compliance with RFC > 4866. > > OPEN ISSUES > > These extensions have to be made compliant with RFC 5648 (multiple > CoA registration), RFC 3963 (NEMO) and others. More discussions are > necessary. > > > > _______________________________________________ MEXT mailing list > MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From Fred.L.Templin@boeing.com Mon Jan 31 09:20:28 2011 Return-Path: <Fred.L.Templin@boeing.com> X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D58F3A6807 for <mext@core3.amsl.com>; Mon, 31 Jan 2011 09:20:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.472 X-Spam-Level: X-Spam-Status: No, score=-6.472 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uBCZmIR8ApVd for <mext@core3.amsl.com>; Mon, 31 Jan 2011 09:20:27 -0800 (PST) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by core3.amsl.com (Postfix) with ESMTP id E3BE73A67F0 for <mext@ietf.org>; Mon, 31 Jan 2011 09:20:26 -0800 (PST) Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by stl-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p0VHNaYR027552 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <mext@ietf.org>; Mon, 31 Jan 2011 11:23:39 -0600 (CST) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id p0VHNajR017768 for <mext@ietf.org>; Mon, 31 Jan 2011 09:23:36 -0800 (PST) Received: from XCH-NWHT-07.nw.nos.boeing.com (xch-nwht-07.nw.nos.boeing.com [130.247.25.111]) by slb-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p0VHNaqQ017748 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK) for <mext@ietf.org>; Mon, 31 Jan 2011 09:23:36 -0800 (PST) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-07.nw.nos.boeing.com ([130.247.25.111]) with mapi; Mon, 31 Jan 2011 09:23:36 -0800 From: "Templin, Fred L" <Fred.L.Templin@boeing.com> To: "mext@ietf.org" <mext@ietf.org> Date: Mon, 31 Jan 2011 09:23:34 -0800 Thread-Topic: IRON - a new approach to mobility management Thread-Index: Acu9ZObUeEtp4wpfT9m3W4BGslqdFwAIrYJQADbmZMAAN/RKAACJyDew Message-ID: <E1829B60731D1740BB7A0626B4FAF0A65C68284039@XCH-NW-01V.nw.nos.boeing.com> References: <AANLkTikGBOTOopf5g0SVvSe1-f1fBK38CN+mSnPdp+8D@mail.gmail.com><E 1829B60731D1740BB7A0626B4FAF0A65C682836E4@XCH-NW-01V.nw.nos.boeing.com><E18 29B60731D1740BB7A0626B4FAF0A65C68283AB4@XCH-NW-01V.nw.nos.boeing.com> <E1829B60731D1740BB7A0626B4FAF0A65C68283EAF@XCH-NW-01V.nw.nos.boeing.com> In-Reply-To: <E1829B60731D1740BB7A0626B4FAF0A65C68283EAF@XCH-NW-01V.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [MEXT] IRON - a new approach to mobility management X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG <mext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/mext> List-Post: <mailto:mext@ietf.org> List-Help: <mailto:mext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 31 Jan 2011 17:20:28 -0000 Here also is the way that operators/providers can make a new business model for themselves: http://www.ietf.org/id/draft-templin-iron-pm-00.txt The customers get to use their same addresses even if they use an access technology other than the native one they get directly from the provider, and the provider gets to market a managed service that customers will recognize as a good value at reasonable rates. Everybody wins, and mobility management with route optimization over multi-access end user devices is naturally supported. Fred fred.l.templin@boeing.com > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On=20 > Behalf Of Templin, Fred L > Sent: Friday, January 28, 2011 3:31 PM > To: mext@ietf.org > Subject: Re: [MEXT] IRON - a new approach to mobility management >=20 > I should also mention that an initial implementation > is available: >=20 > http://www.ietf.org/mail-archive/web/int-area/current/msg02471.html > http://www.ietf.org/mail-archive/web/int-area/current/msg02472.html >=20 > Thanks - Fred > fred.l.templin@boeing.com=20 >=20 > > -----Original Message----- > > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On=20 > > Behalf Of Templin, Fred L > > Sent: Thursday, January 27, 2011 1:01 PM > > To: mext@ietf.org > > Subject: Re: [MEXT] IRON - a new approach to mobility management > >=20 > > Here is another aspect of the proposal that should be > > of interest to this community: > >=20 > > http://www.ietf.org/id/draft-templin-ironmike-00.txt > >=20 > > This shows how the IRON approach aligns with MOBIKE to > > present a system for managing VPN links that allows > > clients to connect to a nearby VPN gateway that in turn > > connects to a trusted and secure network. As clients > > change ISP connections, the VPN gateways naturally learn > > about the changes. As clients move significant distances, > > they simply discover and connect to a different nearby VPN > > gateway. Client-to-client communications then are conveyed > > across the trusted and secure network. Very simple; very > > few moving parts. > >=20 > > Fred > > fred.l.templin@boeing.com=20 > >=20 > > > -----Original Message----- > > > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On=20 > > > Behalf Of Templin, Fred L > > > Sent: Wednesday, January 26, 2011 1:27 PM > > > To: mext@ietf.org > > > Subject: [MEXT] IRON - a new approach to mobility management > > >=20 > > > Hello, > > >=20 > > > I would like to introduce a new approach to mobility > > > management, which is an in-built feature of a new > > > routing and addressing system known as the Internet > > > Routing Overlay Network (IRON): > > >=20 > > >=20 > http://www.rfc-editor.org/internet-drafts/draft-templin-iron-17.txt > > >=20 > > > IRON is a product of the IRTF Routing Research Group > > > (RRG), which was chartered to provide recommendations > > > on addressing the Internet routing scaling issue. While > > > the IRON development effort focused primarily on routing > > > scaling, it soon became clear that mobility management > > > was also naturally afforded by the base architecture > > > with no need for adjunct mechanisms. Also, although this > > > fully-integrated proposal is new many of the concepts were > > > motivated by earlier works. The document therefore cites > > > related initiatives which explored similar concepts. > > >=20 > > > The IRON mobility management approach combines the best > > > aspects of both proactive and on-demand route discovery. > > > IRON Clients (which may include mobile end systems and > > > mobile routers) discover topologically-close IRON Serving > > > routers (i.e., "Servers") and create a connection with > > > one of the Servers for the purpose of maintaining=20 > > > bidirectional tunnel neighbor state. The Client then > > > registers one or more of its interfaces with the Server > > > so that the Server has handles for sending return traffic > > > to the Client. Since the Server can observe the public-side > > > address(es) of the Client without the Client needing to > > > discover them itself, the system therefore also naturally > > > supports a simplified form of NAT traversal.=20 > > >=20 > > > When a Client connects to the Server, the Server sends a > > > "link up" indication via a dynamic routing update that is > > > propagated to a core set of Relay routers (i.e., "Relays"). > > > In practice, there will be O(10's) of Relays while there > > > may be several orders of magnitude more Servers that are > > > topologically distributed throughout the Internet. Only > > > the Relays need maintain a full topology in their routing > > > tables; Servers need only maintain routing table entries > > > for their current set of connected Clients. > > >=20 > > > When a Client 'A' connected to Server 'Y' has a packet to > > > send to a new correspondent Client 'B' connected to Server > > > 'Z', 'A' first tunnels the packet to 'Y' as its default > > > router in the overlay network. Since 'Y' has only partial > > > topology information, it then tunnels the packet to a Relay > > > 'R'. Since 'R' has full topology knowledge, it then tunnels > > > the packet to 'Z' which in turn tunnels the packet to 'B'. > > > At the same time, 'Z' also returns a Redirect message to > > > inform 'Y' that 'Z' is a better next hop in the overlay > > > network to reach 'B'. If 'Y' is configured to forward > > > Redirects to its Clients, it then forwards the Redirect to > > > 'A' which then populates its routing tables with a more- > > > specific route. Otherwise, 'Y' uses the Redirect to update > > > its own routing tables. Hence, route optimization is > > > naturally supported. > > >=20 > > > When 'A' changes its ISP points of attachement (i.e., when > > > 'A' moves), it need not explicitly inform 'Y' of the changes > > > as long as it wishes to retain 'Y' as its Server, since 'Y' > > > will naturally discover any changes in 'A''s address(es) via > > > the source addresses of 'A''s packets. 'A' also need not > > > inform any of its recent correspondents about the changes, > > > since the correspondents can still reach 'A' via 'Y'. Hence, > > > localized mobility events are communicated implicitly and > > > immediately with no need for binding updates. > > >=20 > > > When 'A' moves far away from 'Y', it can leisurely discover > > > a new nearby Server 'W'. It can then connect to 'W' and > > > disconnect from 'Y' which will cause dynamic routing between > > > the overlay network Relays to naturally update 'A''s > > > Client-to-Server bindings. Hence, routing stretch is > > > managed without need for delay-sensitive actions. > > >=20 > > > Finally, the base system does not require Client-to-Client > > > binding updates. For example, if Client 'C' has a routing > > > table for 'A' with next-hop 'Y', but 'A' has moved to a > > > new Server 'W', 'C' will receive Redirect messages from > > > 'Y' informing it that 'A' is now associated with 'W'. > > > Hence, 'A' need not keep track of recent correspondents, > > > since any correspondents will naturally be redirected to > > > 'A's new location without risk of packet loss. (Again, > > > this is a coarse-grained mobility consideration, since > > > 'A' will typically not change to a new Server unless it > > > moves some significant distance, e.g., 1000 miles). > > >=20 > > > Comments and questions welcome, > > >=20 > > > Fred > > > fred.l.etmplin@boeing.com > > > _______________________________________________ > > > MEXT mailing list > > > MEXT@ietf.org > > > https://www.ietf.org/mailman/listinfo/mext > > >=20 > > _______________________________________________ > > MEXT mailing list > > MEXT@ietf.org > > https://www.ietf.org/mailman/listinfo/mext > >=20 > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > =