The IESG | 3 Jan 16:12 2011
Picon

[MEXT] Protocol Action: 'DHCPv6 Prefix Delegation for NEMO' to Proposed Standard (draft-ietf-mext-nemo-pd-07.txt)

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
(Continue reading)

Jari Arkko | 11 Jan 11:54 2011
Picon

[MEXT] suggest charter item for distributed mobility work

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 <at> it.uc3m.es>
     Julien Laganier <julienl <at> qualcomm.com>

 Internet Area Directors:
     Ralph Droms <rdroms.ietf <at> gmail.com>
     Jari Arkko <jari.arkko <at> piuha.net>

 Internet Area Advisor:
     Jari Arkko <jari.arkko <at> piuha.net>

 Mailing Lists:
     General Discussion: mext <at> ietf.org
     To Subscribe:       https://www.ietf.org/mailman/listinfo/mext
     Archive:            http://www.ietf.org/mail-archive/web/mext
(Continue reading)

Sri Gundavelli | 20 Jan 04:14 2011
Picon

Re: [MEXT] suggest charter item for distributed mobility work

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" <jari.arkko <at> 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 <at> it.uc3m.es>
     Julien Laganier <julienl <at> qualcomm.com>

 Internet Area Directors:
     Ralph Droms <rdroms.ietf <at> gmail.com>
     Jari Arkko <jari.arkko <at> piuha.net>

 Internet Area Advisor:
     Jari Arkko <jari.arkko <at> piuha.net>

 Mailing Lists:
     General Discussion: mext <at> 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 <at> ietf.org
https://www.ietf.org/mailman/listinfo/mext
_______________________________________________
MEXT mailing list
MEXT <at> ietf.org
https://www.ietf.org/mailman/listinfo/mext
Jan Zorz @ go6.si | 20 Jan 09:34 2011
Picon

[MEXT] Review of I-D draft-korhonen-mext-mip6-altsec-06

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
jouni korhonen | 20 Jan 10:31 2011
Picon

Re: [MEXT] Review of I-D draft-korhonen-mext-mip6-altsec-06

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  <at>  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.

That is purely an implementation issue. We will add some more text around this topic.

> 
> - 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.

> 
> - Describe the steps in figure 1.

ok.

> 
> - 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.

> 
> - 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.

> 
> - Unclear why HTTP headers (Sec 8.2) are being reserved. Could not
>  really understand the purpose.

Just a left over from earlier revisions.

> 
> - 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.
> 

Thanks.

- Jouni

> Regards, Jan Zorz
> go6.si
> _______________________________________________
> MEXT mailing list
> MEXT <at> ietf.org
> https://www.ietf.org/mailman/listinfo/mext
Jan Zorz @ go6.si | 20 Jan 10:36 2011
Picon

Re: [MEXT] Review of I-D draft-korhonen-mext-mip6-altsec-06

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
Arnaud Ebalard | 20 Jan 10:35 2011

Re: [MEXT] Review of I-D draft-korhonen-mext-mip6-altsec-06


"Jan Zorz  <at>  go6.si" <jan <at> 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
Jari Arkko | 20 Jan 19:25 2011
Picon

Re: [MEXT] suggest charter item for distributed mobility work

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 <at> 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 <at> it.uc3m.es>
>          Julien Laganier <julienl <at> qualcomm.com>
>
>      Internet Area Directors:
>          Ralph Droms <rdroms.ietf <at> gmail.com>
>          Jari Arkko <jari.arkko <at> piuha.net>
>
>      Internet Area Advisor:
>          Jari Arkko <jari.arkko <at> piuha.net>
>
>      Mailing Lists:
>          General Discussion: mext <at> 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 <at> ietf.org
>     https://www.ietf.org/mailman/listinfo/mext
>
Jari Arkko | 20 Jan 20:00 2011
Picon

Re: [MEXT] suggest charter item for distributed mobility work

The IESG has approved the change to the charter in our telechat today.

Jari
Hampel, K Georg (K Georg | 20 Jan 21:07 2011

[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

Bell Laboratories

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 <at> ietf.org
https://www.ietf.org/mailman/listinfo/mext

Gmane