Subject: [MEXT] WG Review: Recharter of Mobility EXTensions for IPv6 (mext)

From: IESG Secretary <[email-masked]>
Date: Tue, 17 Aug 2010 10:30:02 -0700 (PDT)

A modified charter has been submitted for the Mobility EXTensions for IPv6
(mext) working group in the Internet Area of the IETF.  The IESG has not
made any determination as yet.  The modified charter is provided below for
informational purposes only.  Please send your comments to the IESG
mailing list ([email-masked]) by Tuesday, August 24, 2010.

Mobility EXTensions for IPv6 (mext)
---------------------------------------------
Status: Active Working Group
Last updated: 2010-07-28

Chairs:
  Marcelo Bagnulo <[email-masked]>
  Julien Laganier <[email-masked]>

Internet Area Directors:
  Ralph Droms <[email-masked]>
  Jari Arkko <[email-masked]>

Internet Area Advisor:
  Jari Arkko <[email-masked]>

Mailing Lists:
  General Discussion: [email-masked]
  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.

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. One 
specific area of concern that should be analyzed and addressed relates 
to multilink subnets.

Goals and Milestones:

Dec 2010  Submit the final doc on Prefix Delegation for NEMO to the 
          IESG, for Proposed Standard
Jun 2008  Submit the I-D 'RADIUS Mobile IPv6 Support' to IESG for 
          publication as a proposed standard.
Jan 2010  Submit I-D 'Mobile IPv6 Operation with Firewalls' to IESG 
          for publication as Informational.
Dec 2010  Submit I-D(s) related to specific updates and corrections 
          of RFC 3775 to IESG for publication as Proposed Standard.
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

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 24 Aug 2010 15:41:41 +0200

Hello IESG,

Today is the August 24th deadline.  I reply now, although the momentum
around this potential WG item may take longer.

I have suggested during the MEXT re-chartering discussion the inclusion
of an item related to moving network to moving network communications.
Two drafts have been discussed in the WG recently:

       draft-jhlee-mext-mnpp-00.txt
       draft-petrescu-autoconf-ra-based-routing-00.txt

The intended status of the first reads Informational, and of the second
should also be Informational, or Experimental (the current tag is wrong
in the draft).

The two drafts were presented at different MEXT WG meetings, and were
discussed by the authors, publicly.  Two different implementations have
been prototyped.

AUTOCONF WG discussed the second draft a little bit, but I don't think
it will be Chartered there because AUTOCONF seems to be mostly about
DHCP, whereas here it's about RAs and NEMO.

Some comments received recently from non Authors showed an interest in
more feedback from independent persons.  A Chair indicated that more
technical review is needed.  We consider these remarks seriously.

Technically, Router Advertisement extensions are used to exchange routes
between two moving networks.  When infrastructure Internet is not
available, MIP6 NEMO is not triggered.

Alex
Le 17/08/2010 19:30, IESG Secretary a écrit :
> A modified charter has been submitted for the Mobility EXTensions for
> IPv6 (mext) working group in the Internet Area of the IETF.  The IESG
> has not made any determination as yet.  The modified charter is
> provided below for informational purposes only.  Please send your
> comments to the IESG mailing list ([email-masked]) by Tuesday, August
>  24, 2010.
>
>
> --------------------------------------------- Status: Active Working
>  Group Last updated: 2010-07-28
>
> Chairs: Marcelo Bagnulo<[email-masked]> Julien
> Laganier<[email-masked]>
>
> Internet Area Directors: Ralph Droms<[email-masked]> Jari
> Arkko<[email-masked]>
>
> Internet Area Advisor: Jari Arkko<[email-masked]>
>
> Mailing Lists: General Discussion: [email-masked] To Subscribe:
> https://www.ietf.org/mailman/listinfo/mext Archive:
> http://www.ietf.org/mail-archive/web/mext
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>  One specific area of concern that should be analyzed and addressed
> relates to multilink subnets.
>
> Goals and Milestones:
>
> IESG, for Proposed Standard Jun 2008  Submit the I-D 'RADIUS Mobile
> IPv6 Support' to IESG for publication as a proposed standard. Jan
> 2010  Submit I-D 'Mobile IPv6 Operation with Firewalls' to IESG for
> publication as Informational. Dec 2010  Submit I-D(s) related to
> specific updates and corrections of RFC 3775 to IESG for publication
>  as Proposed Standard. 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 _______________________________________________
> IETF-Announce mailing list [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-announce
>

---

From: "Laganier, Julien" <[email-masked]>
Date: Tue, 24 Aug 2010 16:24:21 -0700

Folks - 

Since the comment period is closing for the rechartering I am summarizing what has been discussed on the MEXT mailing list so far. 

Three additional deliverables that fall under the "base specification maintenance" work item of the MEXT WG have been proposed to be included as part of the recharter. So far they have received some support from some WG participants and no opposition. These additional deliverables are:

1. Mobile IPv6 does not have a mechanism to negotiate the protection afforded to payload traffic. Security required for payload traffic depends on the type of access network to which the MN is attached and/or the type of traffic itself. For example, if link-layer security affords confidentiality protection over the air there might be no need for network layer security providing the same between the mobile node and the home agent. This deliverable specifies a mechanism allowing 1) a mobile node to hint at its home agent what its security requirements are, and 2) the home agent to indicate to the mobile node what security protection should be applied as a result, based on the hints from the mobile node and local policy at the home agent.

2. Dual-stack Mobile IPv6 does not have explicit support for overlapping private IPv4 addressing support.  There are number of scenarios where there is a need for a home agent to allocate the same private IPv4 address to multiple mobile nodes that it is serving.  A service provider hosting home agent service for enterprises may be required to allocate IPv4 addresses to mobile nodes from the same overlapping private IPv4 address pool.  Or, when supporting some of the transitioning solutions related to IPv4 address exhaust, a home agent  may have to allocate the same IPv4 address to multiple mobile nodes. This deliverable specifies extensions to Dual-stack Mobile IPv6 for supporting overlapping private IPV4 addressing support.

3. Dynamic Discovery of a Dual Stack Mobile IPv6 Home Agent is not specified for the integrated case (i.e., based on DHCP) when a mobile node is attached to an IPv4 only network. This deliverable specifies DHCPv4 options for dynamic discovery of home network information in Dual Stack Mobile IPv6.  New DHCPv4 options that allows a mobile node to request the home agent IPv4 and IPv6 addresses, FQDN, or home network prefix and obtain it via the DHCPv4 response.

--julien

> -----Original Message-----
> From: IESG Secretary [mailto:[email-masked]]
> Sent: Tuesday, August 17, 2010 10:30 AM
> To: [email-masked]
> Cc: [email-masked]; Laganier, Julien; [email-masked]
> Subject: WG Review: Recharter of Mobility EXTensions for IPv6 (mext)
> 
> IPv6 (mext) working group in the Internet Area of the IETF.  The IESG has
> not made any determination as yet.  The modified charter is provided below
> for informational purposes only.  Please send your comments to the IESG
> above the IP layer, including maintenance of active transport level sessions.
> 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)
> working group will ensure that any issues identified by implementation and
> specifications are maintained. The group will also produce
> informational documentation, such as design rationale documents or description of
> prefix delegation for NEMO, RADIUS  support for Mobile IPv6, Mobile
> IPv6 operation with firewalls, and home agent reliability specifications.
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 25 Aug 2010 18:46:20 +0200

Le 25/08/2010 01:24, Laganier, Julien a écrit :
> Folks -
>
> Since the comment period is closing for the rechartering I am
> summarizing what has been discussed on the MEXT mailing list so far.
>
> Three additional deliverables that fall under the "base
> specification maintenance" work item of the MEXT WG have been
> proposed to be included as part of the recharter. So far they have
> received some support from some WG participants and no opposition.
> These additional deliverables are:
>
> 1. Mobile IPv6 does not have a mechanism to negotiate the protection
> afforded to payload traffic. Security required for payload traffic
> depends on the type of access network to which the MN is attached
> and/or the type of traffic itself. For example, if link-layer
> security affords confidentiality protection over the air there might
> be no need for network layer security providing the same between the
> mobile node and the home agent. This deliverable specifies a
> mechanism allowing 1) a mobile node to hint at its home agent what
> its security requirements are, and 2) the home agent to indicate to
> the mobile node what security protection should be applied as a
> result, based on the hints from the mobile node and local policy at
> the home agent.

What is the risk of security being weakened by this new security
negotiating mechanism as opposed to, let's say, using certificates and PKI.

Why is the afforded link-layer security useful to Mobile IPv6, knowing
that link-layer security stays on a link only, whereas Mobile IPv6 is
much about multiple hops between MN and HA.

> 2. Dual-stack Mobile IPv6 does not have explicit support for
> overlapping private IPv4 addressing support.  There are number of
> scenarios where there is a need for a home agent to allocate the
> same private IPv4 address to multiple mobile nodes that it is
> serving.  A service provider hosting home agent service for
> enterprises may be required to allocate IPv4 addresses to mobile
> nodes from the same overlapping private IPv4 address pool.  Or, when
> supporting some of the transitioning solutions related to IPv4
> address exhaust, a home agent  may have to allocate the same IPv4
> address to multiple mobile nodes. This deliverable specifies
> extensions to Dual-stack Mobile IPv6 for supporting overlapping
> private IPV4 addressing support.
>
> 3. Dynamic Discovery of a Dual Stack Mobile IPv6 Home Agent is not
> specified for the integrated case (i.e., based on DHCP) when a
> mobile node is attached to an IPv4 only network. This deliverable
> specifies DHCPv4 options for dynamic discovery of home network
> information in Dual Stack Mobile IPv6.  New DHCPv4 options that
> allows a mobile node to request the home agent IPv4 and IPv6
> addresses, FQDN, or home network prefix and obtain it via the DHCPv4
> response.

I think IPv4 should be out of scope in the MEXT WG, has nothing to do
with Mobile IPv6.

In general, DS-MIPv6 spec has several incoherent things within: (1)
prefix table of NEMO is absent, yet it says it supports moving networks;
(2) DSMIPv6 doesn't support separated IPv6 HA and IPv4 HA; (3) it
addresses an inexistent problem where IPv6 was largely deployed and IPv4
just showing up (the current landscape is vice-versa).

That said.

If there is a requirement from an SDO about IPv4 and Mobile IPv6, then I
believe it should be hinted at.  What SDO do you think will take
advantage of the proposed DS-MIPv6 extensions?

Alex

>
> --julien
>
>
>> -----Original Message----- From: IESG Secretary
>> [mailto:[email-masked]] Sent: Tuesday, August 17, 2010
>> 10:30 AM To: [email-masked] Cc: [email-masked];
>> Laganier, Julien; [email-masked] Subject: WG Review: Recharter of
>> A modified charter has been submitted for the Mobility EXTensions
>> for IPv6 (mext) working group in the Internet Area of the IETF. The
>> IESG has not made any determination as yet.  The modified charter
>> is provided below for informational purposes only.  Please send
>> your comments to the IESG mailing list ([email-masked]) by Tuesday,
>> August 24, 2010.
>>
>>
>> --------------------------------------------- Status: Active
>> Working Group Last updated: 2010-07-28
>>
>> 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:
>>
>> Operation with IKEv2) o RFC 5555 (Dual Stack Mobile IPv6) o RFC
>> 5648 (Multiple Care-of Addresses Registration) o RFC 5846 (Binding
>> The MEXT Working Group continues the work of the former MIP6,
>> NEMO, and MONAMI6 Working Groups.
>>
>> different implementations. The MEXT WG is chartered to deliver one
>> or more experimental alternative mechanisms. All the alternative
>> 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.
>>
>> issues with specific updates or revisions of the base
>> specification. One specific area of concern that should be
>> analyzed and addressed relates to multilink subnets.
>>
>> Goals and Milestones:
>>
>> specific updates and corrections of RFC 3775 to IESG for
>> publication as Proposed Standard. 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
> _______________________________________________ MEXT mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/mext
>

---

From: Frank Xia <[email-masked]>
Date: Wed, 25 Aug 2010 10:25:41 -0700

Hi Alex

Please see my inline comments regarding SDO 
adoption of "IPv4 and Mobile IPv6".

BR
Frank

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Alexandru Petrescu
Sent: Wednesday, August 25, 2010 9:46 AM
To: [email-masked]
Subject: Re: [MEXT] WG Review: Recharter of Mobility EXTensions for IPv6
(mext)

That said.

Frank=>Please check 3GPP 23.402 specification which states DSMIPv6 
application for s2c interface.  Here is a link for further reference 
http://www.3gpp.org/ftp/Specs/2010-06/Rel-8/23_series/.

Alex

> [email-masked] https://www.ietf.org/mailman/listinfo/mext

_______________________________________________
MEXT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mext

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 25 Aug 2010 19:41:56 +0200

Hi Frank,

Le 25/08/2010 19:25, Frank Xia a écrit :
[...]
> If there is a requirement from an SDO about IPv4 and Mobile IPv6,
> then I believe it should be hinted at.  What SDO do you think will
> take advantage of the proposed DS-MIPv6 extensions?
>

Thanks for the pointer; it is good to have the 3GPP DS-MIPv6 URL in one
place.

It is good to know the DS-MIPv6 extensions are necessary to 3GPP SDO -
it is a strong reason having already motivated much work in MEXT.

Alex

>>> for IPv6 (mext) working group in the Internet Area of the IETF.
>>> The IESG has not made any determination as yet.  The modified
>>> charter is provided below for informational purposes only.
>>> Please send your comments to the IESG mailing list
>>> ([email-masked]) by Tuesday, August 24, 2010.
>>>
>>>
>>> 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)
>>>
>>> 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.
>>>
>>> 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
>>> Dec 2010  Submit the final doc on Prefix Delegation for NEMO to
>>> the IESG, for Proposed Standard Jun 2008  Submit the I-D 'RADIUS
>>> Mobile IPv6 Support' to IESG for publication as a proposed
>>> standard. Jan 2010  Submit I-D 'Mobile IPv6 Operation with
>>> Firewalls' to IESG for publication as Informational. Dec 2010
>>> Submit I-D(s) related to specific updates and corrections of RFC
>>> 3775 to IESG for publication as Proposed Standard. 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

---

From: Jari Arkko <[email-masked]>
Date: Thu, 26 Aug 2010 03:17:17 -0400

These make sense. Thanks, Julien.

Jari