Subject: Re: [MEXT] new charter proposal

From: Frank Xia <[email-masked]>
Date: Tue, 03 Aug 2010 17:11:07 -0700

Hi Chairs

Flow binding revocation was widely discussed and agreed
in previous discussion through mailing list and meetings.

I would like to have it in the new charter.

Best Regards
Frank

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Laganier, Julien
Sent: Wednesday, July 28, 2010 5:37 AM
To: [email-masked]
Cc: Jari Arkko
Subject: [MEXT] new charter proposal

Folks,

For your information, below is the recharter proposal that we've put
together and forwarded to IESG.

--julien

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.

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

Done 	Submit I-D 'Mobile IPv6 Vendor Specific Option' to IESG for
publication as a Proposed Standard
Done 	Submit I-D 'Mobile IPv6 Experimental Allocations' 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
Dec 2010 	Submit the final doc on Prefix Delegation for NEMO to the
IESG, for Proposed Standard
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
Jun 2008 	Submit the I-D 'RADIUS Mobile IPv6 Support' to IESG for
publication as a proposed standard.
Done 	Submit 00 draft on Binding Revocation
Jan 2010 	Submit I-D 'Mobile IPv6 Operation with Firewalls' to IESG
for publication as Informational.
Done 	Submit the final doc on MIB for NEMO Basic Support to the IESG, for
Proposed Standard
Done 	Submit Flow/binding policy transport to IESG, for Proposed Standard
Done	Submit Flow/binding policy format to IESG, for Proposed Standard
Done 	Submit draft on Binding Revocation to IESG	
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

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

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 04 Aug 2010 10:15:10 +0200

Hi Julien, WG,

I would like to discuss addition of an item related to moving network to
moving network communications.  Two drafts have been discussed in the WG
recently, although probably more review is needed:

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

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

AUTOCONF WG discussed the second draft a little bit, but I don't think
it will be Chartered there because that is going to be mostly about DHCP.

What do you Julien, group, think?

Alex

Le 28/07/2010 14:36, Laganier, Julien a écrit :
> 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
> 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.
>
> 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
>
> publication as a Proposed Standard Done 	Submit I-D 'Mobile IPv6
> Experimental Allocations' 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 Dec 2010
> Submit the final doc on Prefix Delegation for NEMO to the IESG, for
> Proposed Standard 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 Jun 2008 	Submit the I-D 'RADIUS
> Mobile IPv6 Support' to IESG for publication as a proposed standard.
> Done 	Submit 00 draft on Binding Revocation Jan 2010 Submit I-D
> 'Mobile IPv6 Operation with Firewalls' to IESG for publication as
> Informational. Done 	Submit the final doc on MIB for NEMO Basic
> Support to the IESG, for Proposed Standard Done 	Submit Flow/binding
> policy transport to IESG, for Proposed Standard Done Submit
> Flow/binding policy format to IESG, for Proposed Standard Done Submit
> draft on Binding Revocation to IESG 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
>
> _______________________________________________ MEXT mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/mext
>

---

From: Sri Gundavelli <[email-masked]>
Date: Wed, 04 Aug 2010 11:54:03 -0700

Hi Julien/Marcelo:

I'd like to get some comments on the following work item. Its a minor
extension to DSMIPv6, trying to see if I can get this into the charter.
Comments/feedback appreciated.

Title: Overlapping IPv4 Address Assignment Support in Dual-stack Mobile IPv6
             
Abstract
 
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 document specifies extensions to Dual-stack Mobile IPv6
for supporting overlapping private IPV4 addressing support.

Regards
Sri

---

From: <[email-masked]>
Date: Fri, 6 Aug 2010 19:32:13 +0200

Hello,

Since we are in the re-chartering discussion, I would like to propose the
inclusion of the feature which enables security to be enabled on a demand
basis for the user-plane traffic. Security for the signaling messages is
mandtory. However security for user-plane traffic depends on the type of
access network to which the MN is attached and/or the type of traffic
itself.

We have presented the following I-D: Security On Demand for Mobile IPv6 and
Dual-stack Mobile IPv6 <draft-bajko-mext-sod-00.txt> at IETF77.

-Basavaraj

On 7/28/10 7:36 AM, "ext Laganier, Julien" <[email-masked]> wrote:

> Folks,
> 
> For your information, below is the recharter proposal that we've put together
> and forwarded to IESG.
> 
> --julien
> 
> 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)
> 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.
> 
> 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.
> 
> 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
> 
> 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.
> Jan 2010        Submit I-D 'Mobile IPv6 Operation with Firewalls' to IESG for
> 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

---

From: "Laganier, Julien" <[email-masked]>
Date: Fri, 20 Aug 2010 16:01:44 -0700

Hi Sri,

This seems to fall under the scope of the proposed charter: " Additionally, the working group will ensure that any issues identified by implementation and interoperability experience are addressed, and that the base specifications are maintained."

What do people think?

--julien

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 23 Aug 2010 09:01:12 -0700 (PDT)

Hi Julien,
  What do you think about DHCPv4 options for dynamic discovery of home    
network information in DSMIPv6? I think that it should also fall into the scope 
of the proposed charter?

Regards,

Behcet

----- Original Message ----
> From: "Laganier, Julien" <[email-masked]>
> To: Sri Gundavelli <[email-masked]>; "[email-masked]" <[email-masked]>
> Cc: Jari Arkko <[email-masked]>
> Sent: Fri, August 20, 2010 6:01:44 PM
> Subject: Re: [MEXT] new charter proposal
> 
> Hi Sri,
> 
> This seems to fall under the scope of the proposed charter: "  Additionally, 
>the working group will ensure that any issues identified by  implementation and 
>interoperability experience are addressed, and that the base  specifications are 
>maintained."
> 
> What do people  think?
> 
> --julien
> 
> Sri Gundavelli wrote:
> > 
> > Hi  Julien/Marcelo:
> >

---

From: "Laganier, Julien" <[email-masked]>
Date: Mon, 23 Aug 2010 11:02:23 -0700

Hello Raj,

Thanks for bringing this up. 

<wg chair hat off>

I personally think that there is value in allowing 1) a mobile node to hint at its home agent what its security requirements are (e.g., if link-layer security affords confidentiality protection over the air there might be no need for network layer security providing the same up to the home agent), 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. 

To some extent, the absence of a mechanism for the MN and the HA to agree on the protection afforded to user plane can be seen as a deficiency as it will complicate roaming where local break-out is in use, i.e., the mobile node is assigned a home agent in a visited network. In such a setting, it can be hard for the mobile node and the home agent to be configured with matching security policies since the two entities belong to different administrative domains.

So I tend to be of the opinion that working on such a mechanism can be considered as maintenance of the base protocol and as such is in scope for the WG.

<wg chair hat on>

Now it would be interesting to see what are the thoughts of other participants to the working group.

--julien

> From: [email-masked] [mailto:[email-masked]]
> Sent: Friday, August 06, 2010 10:32 AM
> To: Laganier, Julien; [email-masked]
> Cc: [email-masked]
> Since we are in the re-chartering discussion, I would like to propose
> the inclusion of the feature which enables security to be enabled on a
> demand basis for the user-plane traffic. Security for the signaling messages
> is mandatory. However security for user-plane traffic depends on the type
> of access network to which the MN is attached and/or the type of traffic
> itself.
> 
> We have presented the following I-D: Security On Demand for Mobile IPv6
> and Dual-stack Mobile IPv6 <draft-bajko-mext-sod-00.txt> at IETF77.
> 
> -Basavaraj
> 
> continue
> mobility
> continuing
> specific
> mechanisms.
> issues with

---

From: <[email-masked]>
Date: Mon, 23 Aug 2010 20:16:21 +0200

Thanks for your feedback.

I look forward to further views from the WG. I do hope that we can take up
this work in the revised charter and would be happy to clarify any questions
or comments that come up.

-Raj

On 8/23/10 1:02 PM, "ext Laganier, Julien" <[email-masked]> wrote:

> I personally think that there is value in allowing 1) a mobile node to hint at
> its home agent what its security requirements are (e.g., if link-layer
> security affords confidentiality protection over the air there might be no
> need for network layer security providing the same up to the home agent), 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.
> 
> To some extent, the absence of a mechanism for the MN and the HA to agree on
> the protection afforded to user plane can be seen as a deficiency as it will
> complicate roaming where local break-out is in use, i.e., the mobile node is
> assigned a home agent in a visited network. In such a setting, it can be hard
> for the mobile node and the home agent to be configured with matching security
> policies since the two entities belong to different administrative domains.
> 
> So I tend to be of the opinion that working on such a mechanism can be
> considered as maintenance of the base protocol and as such is in scope for the
> WG.
> 
> <wg chair hat on>
>

---

From: "Laganier, Julien" <[email-masked]>
Date: Mon, 23 Aug 2010 12:36:07 -0700

Hi Behcet,

Behcet Sarikaya wrote:
> network information in DSMIPv6? I think that it should also fall into
> the scope of the proposed charter?

My recollection is that last time you presented this at a MEXT WG session there was significant push-back based on the ground that there is already a DHCP option defined to indicate Mobile IP agents to a mobile node, e.g., RFC 2132.

--julien

---

From: Frank Xia <[email-masked]>
Date: Mon, 23 Aug 2010 14:31:50 -0700

Julien

I had a clarification on April 26 mailing 
http://www.ietf.org/mail-archive/web/mext/current/msg04147.html.

In summary, " RFC2132 only defines option  for *IPv4* home agent address,
while our proposal describes DHCPv4 option to carry *IPv6* home agent
address."

BR
Frank

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Laganier, Julien
Sent: Monday, August 23, 2010 12:36 PM
To: Behcet Sarikaya; Sri Gundavelli; [email-masked]
Cc: Jari Arkko
Subject: Re: [MEXT] new charter proposal

Hi Behcet,

> the scope of the proposed charter?

My recollection is that last time you presented this at a MEXT WG session
there was significant push-back based on the ground that there is already a
DHCP option defined to indicate Mobile IP agents to a mobile node, e.g., RFC
2132.

--julien

---

From: "Laganier, Julien" <[email-masked]>
Date: Mon, 23 Aug 2010 16:27:52 -0700

Frank,

Thanks for the pointer. Let's see what the WG think.

--julien

---

From: Frank Xia <[email-masked]>
Date: Mon, 23 Aug 2010 17:29:10 -0700

Hi Julien

Please also check the thread
http://www.ietf.org/mail-archive/web/mext/current/msg02721.html

AFAIK, Jari, Hesham, Raj, Vijay, Heejin and me all thought that
this work needed to be done.

If you can't find proof, please let me know. I can send you
corresponding links.

BR
Frank

-----Original Message-----
From: Laganier, Julien [mailto:[email-masked]] 
Sent: Monday, August 23, 2010 4:28 PM
To: Frank Xia; 'Behcet Sarikaya'; 'Sri Gundavelli'; [email-masked]
Cc: 'Jari Arkko'
Subject: RE: [MEXT] new charter proposal

Frank,

--julien

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 24 Aug 2010 12:00:26 -0700

Seems like a useful extension. But it is not clear how this will work 
with IPsec SAs used for protecting the payload traffic. When user plane 
encryption is not required, is the corresponding SA torn down? And when 
it is required, is it setup? But this has implications on the handover. 
There will be multiple round trips to setup the IPsec SA in the middle 
of a handover if the user moves from a secured access to an unsecured 
access network.

If you want to avoid that, you need a new mechanism to somehow tell the 
IPsec module to "de-activate" and "active" the IPsec SA that is already 
setup, both on the mobile node and the home agent. This is going to be 
tricky, to say the least. :)

Vijay

On 8/23/10 11:02 AM, Laganier, Julien wrote:
>> and Dual-stack Mobile IPv6<draft-bajko-mext-sod-00.txt>  at IETF77.
>>
>> -Basavaraj
>>
>> On 7/28/10 7:36 AM, "ext Laganier, Julien"<[email-masked]>
>> wrote:
>>
>>> Folks,
>>>

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 24 Aug 2010 12:15:29 -0700

> of a handover if the user moves from a secured access to an unsecured

Its actually one round trip to setup a additional CHILD SA. Not multiple 
round trips. Maybe its not so bad after all.

Vijay

>> I personally think that there is value in allowing 1) a mobile node to
>> hint at its home agent what its security requirements are (e.g., if
>> link-layer security affords confidentiality protection over the air
>> there might be no need for network layer security providing the same
>> up to the home agent), 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.
>>
>> To some extent, the absence of a mechanism for the MN and the HA to
>> agree on the protection afforded to user plane can be seen as a
>> deficiency as it will complicate roaming where local break-out is in
>> use, i.e., the mobile node is assigned a home agent in a visited
>> network. In such a setting, it can be hard for the mobile node and the
>> home agent to be configured with matching security policies since the
>> two entities belong to different administrative domains.
>>
>> considered as maintenance of the base protocol and as such is in scope
>> for the WG.
>>
>> <wg chair hat on>
>>

---

From: "Laganier, Julien" <[email-masked]>
Date: Tue, 24 Aug 2010 12:53:28 -0700

Hi Vijay,

Thank you for your feedback. The SA affording integrity and optionally confidentiality protection to payload traffic can be kept around, and the SPD entry activated/de-activated based on the signaling for on-demand security contained in the Binding Update and the Binding Acknowledgment.

--julien 

Vijay Devarapalli wrote:
> > I personally think that there is value in allowing 1) a mobile node
> to hint at its home agent what its security requirements are (e.g., if
> there might be no need for network layer security providing the same up
> to the home agent), and 2) the home agent to indicate to the mobile
> > So I tend to be of the opinion that working on such a mechanism can
> be considered as maintenance of the base protocol and as such is in
> scope for the WG.
> >
> > <wg chair hat on>
> >
> >>> addressed, and that the base specifications are maintained. The
> group
> >> will
> >>> chartered to deliver one or more experimental alternative
> mechanisms.
> >> All the
> >>> specific updates or revisions of the base specification. One
> specific
> >> area of
> >>> Dec 2010        Submit the final doc on Prefix Delegation for NEMO
> to
> >> the
> >>> Jan 2010        Submit I-D 'Mobile IPv6 Operation with Firewalls'
> to
> >> IESG for
> >>> Aug 2011        Submit I-Ds on alternative security mechanisms to
> the
> >> IESG for

---

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

Hi Alex,

IMHO this does not fit in the MEXT WG since this is orthogonal to the Mobile IPv6 suite of protocols (i.e., it doesn't build on, or extend.)

--julien

> Alexandru Petrescu
> Sent: Wednesday, August 04, 2010 1:15 AM
> To: [email-masked]
> Subject: Re: [MEXT] NEMO MNP in RA Informational/Experimental item?
> (was: new charter proposal)
> 
> Hi Julien, WG,
>

---

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

Le 25/08/2010 01:07, Laganier, Julien a écrit :
> Hi Alex,
>
> IMHO this does not fit in the MEXT WG since this is orthogonal to
> the Mobile IPv6 suite of protocols (i.e., it doesn't build on, or
> extend.)

Julien, thanks for the reply.

In a sense yes, this is an RA extension, not an MIPv6 extension.
However, MIPv6 too modifies RAs (HAs, adv interval, etc.)

Otherwise, where do you think there could be a better place (tm) for
these MNP-in-RA drafts?

Any opinion welcome.

Thanks,

Alex

>
> --julien
>
>> -----Original Message----- From: [email-masked]
>> [mailto:[email-masked]] On Behalf Of Alexandru Petrescu
>> Sent: Wednesday, August 04, 2010 1:15 AM To: [email-masked]
>> I would like to discuss addition of an item related to moving
>> network to moving network communications.  Two drafts have been
>> discussed in the WG recently, although probably more review is
>> needed:
>>
>> 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).
>>
>> Router Advertisement extensions are used to exchange routes
>> between two moving networks.  When infrastructure Internet is not
>> available, MIP6 NEMO is not triggered.
>>
>> AUTOCONF WG discussed the second draft a little bit, but I don't
>> think it will be Chartered there because that is going to be
>> mostly about DHCP.
>>
>>> For your information, below is the recharter proposal that we've
>>> put together and forwarded to IESG.
>>>
>>> --julien
>>>
>>> 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.
>>>
>>> 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
>>> 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
>>>
>>> Standard Done 	Submit I-D 'Mobile IPv6 Dual-Stack Operation' to
>>> IESG for publication as a Proposed Standard. Done Submit I-D
>> 'Motivation
>>> Informational. Done 	Submit -00 draft on Route Optimization
>>> Needs
>> for
>>> Optimization Needs for Aircraft and Spacecraft Deployments Dec
>>> 2010 Submit the final doc on Prefix Delegation for NEMO to the
>>> IESG, for Proposed Standard 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 Jun 2008 	Submit the
>>> I-D 'RADIUS Mobile IPv6 Support' to IESG for publication as a
>>> proposed standard. Done 	Submit 00 draft on Binding Revocation
>>> Jan 2010 Submit I-D 'Mobile IPv6 Operation with Firewalls' to
>>> IESG for publication as Informational. Done 	Submit the final
>>> doc on MIB for NEMO Basic Support to the IESG, for Proposed
>>> Standard Done 	Submit
>> Flow/binding
>>> Flow/binding policy format to IESG, for Proposed Standard Done
>>> Submit draft on Binding Revocation to IESG 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: "Laganier, Julien" <[email-masked]>
Date: Wed, 25 Aug 2010 16:26:00 -0700

> However, MIPv6 too modifies RAs (HAs, adv interval, etc.)

MIPv6 modifies RAs to carry MIPv6 information. The extensions you propose do not, on the other hand, carry anything related to MIPv6. So it seems this is different.
 
> Otherwise, where do you think there could be a better place (tm) for

RAs belongs to 6man but it's maintenance so it doesn't look like a good fit. Maybe that needs a BoF.

--julien

---

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

I agree with Julien, and probably the right avenue would be to propose a 
BOF and gather others who think this would be useful. (But is this 
similar to what was discussed years ago in MANEMO, and didn't we decide 
to not take that on for various reasons?)

Jari

Laganier, Julien kirjoitti:
>>>  for publication as a Proposed Standard. Done 	Submit I-D
>>>       
>> 'Motivation
>>     
>>> Informational. Done 	Submit -00 draft on Route Optimization Needs
>>>       
>> for
>>     
>>> Automobile and Highway Deployments Done 	Submit -00 draft on
>>>       
>> Route
>>     
>>> Proposed Standard Done 	Submit I-D 'Mobility Header Home Agent
>>>       
>> Switch
>>     
>>> Support to the IESG, for Proposed Standard Done 	Submit
>>>       
>> Flow/binding
>>

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 26 Aug 2010 11:11:51 +0200

Le 26/08/2010 09:16, Jari Arkko a écrit :
> I agree with Julien, and probably the right avenue would be to
> propose a BOF and gather others who think this would be useful.

Ok, BoF could be an idea.  Let me tell some of my thoughts on
this, currently.

The required work for building a BoF is probably more than a
simple INFORMATIONAL WG item in an existing group.

For example, 6MAN usually quickly takes on such small items (DNS address
in RA was an EXPERIMENTAL draft and RFC, then evolved on StdsTrack),
without even re-chartering.  Why wouldn't MEXT do it.

For building a BoF, there would be a need to precisely identify new
industry support from multiple parties and interested SDOs, etc.
Whereas this MNP-in-RA is work issued already from such support since a
few years.

In MEXT there is an Automotive requirements WG item (expired)
mext-nemo-ro-automotive-req, which mentions vehicle-to-vehicle V2V
requirements, to which the MNP-in-RA is a potential solution.  That is a
potential reason for bringing MNP-in-RA in MEXT.

Technically, for BoF there would be a need for additional mechanisms to
accompany MNP-in-RA, like security, MIB, in order to motivate an entire
WG.  I haven't yet seen much interest for this (except security).

A short-lived WG lasts around 3 years which is seems too long for such a
small RA extension.

It is not clear to me at this stage which of those paths to engage on,
but looking forward to next events unfolding as I speak, and advice from AD.

> (But is this similar to what was discussed years ago in MANEMO, and
> didn't we decide to not take that on for various reasons?)

MNP-in-RA is indeed very similar to what was presented in 2007 in MANEMO
barbof, along with techniques for MIP+MANET, or MANET Gateway.  At that
time it was a new idea, not much cooked, not implemented, not demonstrated.

It was indeed decided to not take MNP-in-RA on in MANEMO.

Then, MANEMO WG didn't form at all, not _any_ of the MANEMO ideas were
taken on.  That potential work was redirected to AUTOCONF, instead of
forming a WG; there something completely different was actually done:
addressing model for MANET, and now DHCP for MANET.

Alex

>>> Subject: Re: [MEXT] NEMO MNP in RA Informational/Experimental
>>> item? (was: new charter proposal)
>>>
>>> Hi Julien, WG,
>>>
>>>> For your information, below is the recharter proposal that
>>>> we've put together and forwarded to IESG.
>>>>
>>>> --julien
>>>>
>>>> Mobile IPv6 specifies routing support which permits an IPv6
>>>> host to continue using its home address as it moves around the
>>>> 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
>>>> IPv6 Operation with IKEv2) o RFC 5555 (Dual Stack Mobile IPv6)
>>>> o RFC 5648 (Multiple Care-of Addresses Registration) o RFC 5846
>>>> 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.
>>>>
>>>> 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
>>>>
>>>> Done Submit I-D 'Mobile IPv6 Vendor Specific Option' to IESG
>>>> for publication as a Proposed Standard Done Submit I-D 'Mobile
>>>> IPv6 Experimental Allocations' 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
>>>> Proposed Standard. Aug 2011 Submit I-Ds on alternative
>>>> security mechanisms to the IESG for publication as
>>>> experimental
>>>>
>>>> _______________________________________________ MEXT mailing
>>>> list [email-masked] https://www.ietf.org/mailman/listinfo/mext
>>>>

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 26 Aug 2010 11:24:38 +0200

Alex

>>> second should also be Informational, or Experimental (the
>>> current tag is wrong in the draft).
>>>
>>>> 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 5648 (Multiple Care-of Addresses Registration) o RFC
>>>> 5846 (Binding Revocation) o RFC-to-be (Flow Binding Policy
>>>> Transport and Flow Binding Policy Format)
>>>>
>>>> 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.
>>>>
>>>> Operation' to IESG for publication as a Proposed Standard. Done
>>>> Submit I-D
>>> 'Motivation

---

From: Thierry Ernst <[email-masked]>
Date: Mon, 30 Aug 2010 18:52:54 +0200

Hi Julien, Alex,

It depends where you stand from. As pointed out by Alex, in the previous 
MEXT charter there is an Automotive requirements WG item and the 
associated draft
draft-mext-nemo-ro-automotive-req (expired, but authors are on the way 
to update it -- also note that ETSI and ISO are going their way in 
specifying standards that will at some time require discussion with 
IETF), "which mentions vehicle-to-vehicle V2V
requirements, to which the MNP-in-RA is a potential solution.  That is a
potential reason for bringing MNP-in-RA in MEXT.".

Of course, should such a solution for a MEXT draft requirement by 
chosen, one might wonder which IETF WG is the best and MEXT might not, 
or might.

On this specific point I consider that a BOF is premature.  First, 
draft-mext-nemo-ro-automotive-req must be updated, and a sufficient 
number of people be interested in the solution. Now, ETSI and ISO are 
working on non-IP issues, and only later will they be concerned about IP 
solutions, including MR-MR RO. Things could change quickly, though I 
don't see a window in 2010.

Regards,
Thierry.