[MEXT] FW: I-D Action:draft-haddad-mext-mobisoc-00.txt

Hi all,

I'd like to mention the following new draft:

Title:  Enhancing Mobile IPv6 Route Optimization Mode with Secure Social Dimension
	
This memo describes an enhancement to Mobile IPv6 route optimization mode which 
is derived from introducing a social dimension within the home network.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-haddad-mext-mobisoc-00.txt

Comments are welcome!

Regards,

Wassim H.

Re: [MEXT] Questions about the draft-ietf-mext-flow-binding-02

> Hello hesham
> 
>      I have read the draft-ietf-mext-flow-binding-02, and i have a question
> about the draft.
> 
> When the flow binding list is create for the MN, the HA or LMA must check the

=> The LMA is not supported in this draft, only the HA, MAP or CN can
receive a BU from the MN.

> type of the packet which is sent to the MN, and then check which Flow Binding
> Entry is matched with this packet. In the home link or LMA domian there maybe
> a lot of MNs, and checking the packet maybe cost some time, so it will affect
> the efficiency of packet forwarding seriously.

=> This is already done today by routers very efficiently for load balancing
different flows. The whole thing can be done in hardware on the fast path of
course using hash tables ...etc. There is nothing new in this draft to
warrant concerns about performance.

Hesham

> 
> Wudi Ye
> 
> 2009-7-2

[MEXT] FW: Questions about the draft-ietf-mext-flow-binding-02

Sorry forgot to copy the list.

------ Forwarded Message
> From: Hesham Soliman <hesham <at> elevatemobile.com>
> Date: Fri, 03 Jul 2009 19:48:24 +1000
> To: 叶武迪 <wudiye_tc3 <at> 163.com>
> Conversation: Questions about the draft-ietf-mext-flow-binding-02
> Subject: Re: Questions about the draft-ietf-mext-flow-binding-02
> 
> 
>>> => This is already done today by routers very efficiently for load balancing
>>> different flows. The whole thing can be done in hardware on the fast path of
>>> course using hash tables ...etc. There is nothing new in this draft to
>>> warrant concerns about performance.
> 
>> Dosen't it need Deep Packet Inspection for flow type checking?
> 
> => Not necessarily, it depends on how you defined the flow. If you only use
> protocols, addresses, spi, or even port numbers that should cover almost all
> of the use cases. Once the flow label is in use it would eliminate the need
> for port numbers. You only need deep inspections if you're looking for payload
> information, which I suspect will be a very rare case. But if that's needed
> then you should pay the price for that. But most firewalls do deep inspections
> today anyway. 
> 
> Hesham
> 
> 
> 
>>> 

[MEXT] NEXTEXT2 BOF

To the Chair and authors of the NEXTEXT2 BOF in particular,

I am pleased to see the consideration of the challenges of multi-layer
mobility being considered here. I support the idea of considering, as the
draft authors suggest below, 

Layer 2 mobility models (independent of L3 methods)
- Because these could support models with either network based global
mobility (such as PMIP) or client based mobility (CMIP) or independent local
mobility without the "L3 methods." Although the latter might apparently seem
to indicate no need to improvements in IETF, this is not necessarily the
case. This is because there could be (I believe there is) demand for layered
approaches to mobility wherein a service provider or entity might want to
layer mobility on top of mobility. Although such methods could be made to
work off the shelf, the demand for fast mobility (such as FMIP) could be
difficult to accomplish without cross-layer signaling.

Hybrid Layer 2/3
- I'm not sure how this differs from the above. If we assume an independent
L2 model (CAPWAP, LWAP, L2TP, etc.) L3 would, by definition -- not "know"
about the underlying L2 mobility. Is hybrid to mean that the layers MUST of
necessity know to work together or CHOULD/SHOULD know. This might be the
same as what I describe above. My only comment is that I think it is helpful
to both support independent L2 from L3, but also allow cross-layer signaling
to assist or expedite event handling

Layer 3 (independent of L2 technologies)
- Still quite valuable when being applied across multiple ran/wireline
technologies
- As the above comments suggest, even where there is "apparently" L3

[MEXT] [Technical Errata Reported] RFC5555 (1805)

The following errata report has been submitted for RFC5555,
"Mobile IPv6 Support for Dual Stack Hosts and Routers".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=5555&eid=1805

--------------------------------------
Type: Technical
Reported by: Julien Laganier <julien.laganier.ietf <at> googlemail.com>

Section: 8

Original Text
-------------
      The IPv4 home address option described in Section 3.1.1 has been
      assigned value 29.  This option is included in the mobility header
      described in [RFC3775].

      The IPv4 address acknowledgement option described in Section 3.2.1
      has been assigned value 29.  This option is included in the
      mobility header described in [RFC3775].

Corrected Text
--------------
      The IPv4 home address option described in Section 3.1.1 has been
      assigned value 29.  This option is included in the mobility header
      described in [RFC3775].

Re: [MEXT] Moving forward with MEXT documents - review of draft-ietf-mip6-hareliability-04

Hi Arnaud,

I submitted the new version (-05).
Most of your comments were solved in this version.

Please review it and confirms the update (see the inline messages, I  
list up the changes).

On 2009/05/04, at 6:10, Arnaud Ebalard wrote:

> Hi,
>
> Some comments on an inline version of draft-ietf-mip6-hareliability-04
> are provided below.
>
> From a general standpoint, I think the document is useful and provides
> a sensible solution to the problem while taking into account the  
> various
> difficulties and possible cases.
>
> That been said, at some point during the reading, I started  
> considering
> that the most interesting review would be (as usual) from someone that
> would have tried implementing *and testing* the protocol. Ryuji, are  
> you
> aware of some tentative implementation or is it only a pure spec at  
> the
> moment?
>
> Just a thought before starting: I understand the technical  

[MEXT] I-D Action:draft-ietf-mip6-hareliability-05.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Mobility EXTensions for IPv6 Working Group of the IETF.

	Title           : Home Agent Reliability Protocol
	Author(s)       : R. Wakikawa
	Filename        : draft-ietf-mip6-hareliability-05.txt
	Pages           : 47
	Date            : 2009-07-13

The home agent can be a single point of failure when Mobile IPv6 is
operated in a system.  It is critical to provide home agent
reliability in the event of a home agent crashing or becoming
unavailable.  This would allow another home agent to take over and
continue providing service to the mobile nodes.  This document
describes the problem scope briefly and provides a mechanism of home
agent failure detection, home agent state transfer, and home agent
switching for home agent redundancy and reliability.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mip6-hareliability-05.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

[MEXT] FW: New Version Notification for draft-ietf-mext-flow-binding-03

Folks, 

I just sbumitted the new version and contains all comments to date.

Hesham

------ Forwarded Message
> From: IETF I-D Submission Tool <idsubmission <at> ietf.org>
> Date: Mon, 13 Jul 2009 03:39:29 -0700 (PDT)
> To: Hesham Soliman <hesham <at> elevatemobile.com>
> Cc: Hesham Soliman <hesham <at> elevatemobile.com>,
> <nicolas.montavont <at> telecom-bretagne.eu>, <koo <at> comnets.uni-bremen.de>
> Subject: New Version Notification for draft-ietf-mext-flow-binding-03
> 
> 
> A new version of I-D, draft-ietf-mext-flow-binding-03.txt has been successfuly
> submitted by Hesham Soliman and posted to the IETF repository.
> 
> Filename:  draft-ietf-mext-flow-binding
> Revision:  03
> Title:   Flow Bindings in Mobile IPv6 and NEMO Basic Support
> Creation_date:  2009-07-13
> WG ID:   mext
> Number_of_pages: 32
> 
> Abstract:
> 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.

[MEXT] I-D Action:draft-ietf-mext-flow-binding-03.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Mobility EXTensions for IPv6 Working Group of the IETF.

	Title           : Flow Bindings in Mobile IPv6 and NEMO Basic Support
	Author(s)       : H. Soliman, et al.
	Filename        : draft-ietf-mext-flow-binding-03.txt
	Pages           : 32
	Date            : 2009-07-13

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.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mext-flow-binding-03.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

_______________________________________________
MEXT mailing list
MEXT <at> ietf.org
https://www.ietf.org/mailman/listinfo/mext

[MEXT] Revised I-D: Problems with the use of IPsec as the security protocol for Mobile IPv6

FYI,

A new version of I-D, draft-patil-mext-mip6issueswithipsec-01.txt has been
successfuly submitted by Basavaraj Patil and posted to the IETF repository.

Filename:        draft-patil-mext-mip6issueswithipsec
Revision:        01
Title:           Problems with the use of IPsec as the security protocol for
Mobile IPv6
Creation_date:   2009-07-13
WG ID:           Independent Submission
Number_of_pages: 15

Abstract:
Mobile IPv6 as specified in RFC3775 relies on IPsec for security.  An
IPsec SA between the mobile node and the home agent provides security
for the mobility signaling.  Use of IPsec for securing the data
traffic between the mobile node and home agent is optional.  This
document analyses the implications of the design decision to mandate
IPsec as the default security protocol for Mobile IPv6 and
consequently Dual-stack Mobile IPv6 and recommends revisiting this
decision in view of the experience gained from implementation and
adoption in other standards bodies.