[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

[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

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

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

[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

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

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

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

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
>

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

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

Jari

[MEXT] Support of route optimization in *absence* of HA

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