Subject: [Mip6] Merged WG charter

From: Jari Arkko <[email-masked]>
Date: Tue, 19 Jun 2007 01:02:26 +0300

Hi all,

Please find below the first draft charter for the merged
WG. Comments appreciated.

Note that the charter has changed only in terms of merging
material from the three working groups into one, shortening
the text here and there, and removing completed items. I've
taken bootstrapping away as a completed item even if we are
still a few weeks away from sending the last document (the
option) to the IESG.

Replies set to mip6 list.

Jari

----

Mobility EXTensions for IPv6 (MEXT)

Chair(s):
TBD

Internet Area Director(s):
Jari Arkko <[email-masked]>
Mark Townsley <[email-masked]>

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

Mailing Lists:
TBD

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, NEMO network mobility 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
o RFC 3776
o RFC 3963

The primary goal of the MEXT working group will be to enhance base
IPv6 mobility by continuing work on developments that are required for
wide-scale deployments and specific deployment scenarios
(A). Additionally the working group will ensure that any issues
identified by implementation and interoperability experience are
addressed, and that the base specifications are maintained (B). The
group will also produce informational documentation, such as design
rationale documents or description of specific issues within the
protocol (C).

Deployment considerations call for solutions to enable
dual-stack operation (A.1), allow the use of multiple interfaces in
mobile nodes (A.2), mechanisms to support high-availabity home agents
(A.3), and ways to employ Mobile IPv6 in the presence of firewalls
(A.4). In addition, there are specific needs of the automotive and
aviation communities with regards to route optimization of network
mobility (A.5).

Work items related to large scale deployment include:

(A.1) A Solution for MIP6 session continuity for dual stack hosts which
      attach to IPv4 access networks. Additionally provide a mechanism
      for carrying IPv4 packets via the Home agent for MIP6 capable
      dual-stack hosts.

(A.2) A protocol based solution for enhancing the reliability of home
      agents and a method to force a host to switch home agents.

      A mechanism to force an MN to switch the HA that is currently
      serving it. This is required in deployments where the HA may need to
      be taken offline for maintenance.

(A.3) Use of multiple interfaces.
    
      The protocols do not today provide support for simultaneous
      differentiated use of multiple access technologies, although
      several proposals exist for such support, and some of them have
      been implemented and tested.
    
      When a mobile host/router uses multiple network interfaces
      simultaneously, or when multiple prefixes are available on a
      single network interface, the mobile host/router would end up
      with multiple Care-of Addresses (CoAs). In addition, the Home
      Agent might be attached to multiple network interfaces, or to a
      single network interface with multiple prefixes, hence resulting
      in the option to use multiple IP addresses for the Home
      Agent. This could result in the possibility of using a multitude
      of bi-directional tunnels between pairs of {Home Agent address,
      CoA} and a number of associated issues: establishment, selection
      and modification of multiple simultaneous tunnels.
    
      The objective of the WG is to produce a clear problem statement
      and to produce standard track specifications to the problems
      associated with the simultaneous use of multiple addresses for
      either mobile hosts using Mobile IPv6 or mobile routers using
      NEMO Basic Support and their variants (FMIPv6, HMIPv6,
      etc). Where the effects of having multiple prefixes on a single
      interface is identical to the effects of having multiple
      interfaces each with a single prefix, the WG will consider a
      generalized approach to cater for multiple prefixes available to
      a mobile host/router.
    
      The WG does not plan to define a tunnel selection mechanism, but
      may document how to use existing mechanisms based upon
      preferences or policies. In particular, the WG will consider
      that a tunnel is alive as long as packets can be exchanged with
      the corresponding peer. In addition, local information, such as
      interface up/down events, or other failure detection mechanisms
      can be used to quickly detect failure of tunnel(s).
    
      Deliverables related to this include
    
      - A document explaining the motivations for a node using multiple
        interfaces and the scenarios where it may end up with multiple
        global addresses on its interfaces [Informational]
    
      - An analysis document explaining what are the limitations for
        mobile hosts using multiple simultaneous Care-of Addresses and Home
        Agent addresses using Mobile IPv6, whether issues are specific to
        Mobile IPv6 or not [Informational].
    
      - A protocol extension to support the registration of multiple
        Care-of Addresses at a given Home Agent address [Standard
        Track].
    
      - A "Flow/binding policies exchange" solution for an exchange of
        policies from the mobile host/router to the Home Agent and from the
        Home Agent to the mobile host/router influencing the choice of the
        Care-of Address and Home Agent address [Standard Track].

(A.4) Work on solutions to deal with firewalls and the problems that
      firewalls cause as identified in RFC 4487.

(A.5) Route optimization of network mobility.

      Three use cases have been identified for this. These are called
      the Aviation case, the Automotive case, and the Personal Mobile
      Router (consumer electronics) case, though the actual technical
      problems are characterized by the type of movements and
      environments more than by the specific industry using the
      technology. The group will explore these cases to gather
      requirements and proceed with solving the open issues.
    
      (1) Airline and spacecraft community, who are deploying NEMO for
      control systems, as well as Internet connectivity and
      entertainment systems. This use case is characterized by fast (~
      1000 km/h) moving objects over large distances (across
      continents). The main technical problem is that tunneling-based
      solutions imply a roundtrip to another continent and that BGP
      based solutions imply significant churn in the global Internet
      routing table.
    
      (2) Automotive industry who are deploying NEMO for in-car
      communication, entertainment, and data gathering, possible
      control systems use, and communication to roadside devices. This
      use case is characterized by moderately fast (~ 100-300 km/h)
      moving objects that employ local or cellular networks for
      connectivity.
    
      (3) Personal Mobile Routers, which are consumer devices that
      allow the user to bring a NEMO network with the user while
      mobile, and communicate with peer NEMO networks/MNNs.
    
      After gathering the requirements for these types of deployments,
      the working group will evaluate what type of route optimization
      needs to be performed (if any), and formulate a solution to
      those problems.
    
      If no requirements for those scenarios can be collected by the
      deadline, it will be assumed that the work is premature, and
      that type of deployment will be dropped from the WG.
    
      The group will only consider airline and spacecraft solutions
      that combine tunneling solutions for small movements with either
      federated tunnel servers or slowly changing end host prefixes.
      The group will only consider personal mobile router requirements
      about optimized routes to another mobile router belonging to the
      same operator. The group will only consider automotive industry
      requirements to allow MR-attached hosts to directly access the
      network where MR has attached to. Work on automotive and
      personal mobile router solutions requires rechartering.
    
      The WG will not consider routing issues inside the mobile
      network. Existing routing protocols (including MANET protocols)
      can be used to solve these problems. The group will also not
      consider general route optimization, multihoming, or other
      problems that are not related to the deployment and maintenance
      of NEMO networks. Similarly, the group will not consider or rely
      on the results of general routing architecture, Internet
      architecture, or identifier-locator split issues that are
      discussed in separate, long term efforts elsewhere in the
      IETF. Finally, the group will not consider solutions that
      require changes from correspondent nodes in the general Internet

Work items related to base specification maintenance include:

(B.1) 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.

      This work item relates only to corrections and
      clarifications. The working group shall not revisit design
      decisions or change the protocol.

(B.2) Update the IANA considerations of RFC 3775 to allow extensions for
      experimental purposes as well passing of optional vendor-specific
      information.

(B.3) Finish working group documents that are currently in process, and
      submit for RFC. This includes prefix delegation protocol mechanism
      for network mobility, and a MIB for NEMO Basic Support.

Work items related to informational documentation include:

(C.1) Produce a design rationale that documents the historical
      thinking behind the introduction of an alternative security
      mechanism, the Authentication Protocol (RFC 4285).

Goals and Milestones:

Jul 2007	Submit -00 draft on Route Optimization Needs for Aircraft and Spacecraft Deployments
Jul 2007	Submit -00 draft on Route Optimization Needs for Automobile and Highway Deployments
Jul 2007	Submit -00 draft on Route Optimization needs for Personal Mobile Router
Aug 2007	Submit Multiple CoA Registration to IESG
Aug 2007	Submit I-D 'Motivation for Authentication I-D' to IESG for publication as Informational.
Aug 2007	Submit I-D 'Goals for AAA HA Interface' to IESG for publication as Informational.
Sep 2007	Submit I-D 'Mobility Header Home Agent Switch Message' to IESG for publication as a Proposed Standard.
Sep 2007	Submit Analysis of the use of Multiple Simultaneous Care-of Addresses and Home Agent addresses in Mobile IPv6
Sep 2007	Submit -00 draft for solution to aircraft/spacecraft problem
Sep 2007	Submit I-D 'Home agent reliability' to IESG for publication as a Proposed Standard.
Sep 2007	Submit I-D 'Mobile IPv6 Dual-Stack Operation' to IESG for publication as a Proposed Standard.
Oct 2007	Submit Multiple Interfaces Motivations and Scenario to IESG, for Informational
Oct 2007	Submit I-D 'Mobile IPv6 Vendor Specific Option' to IESG for publication as a Proposed Standard
Nov 2007	Submit final doc on Route Optimization Needs for Aircraft and Spacecraft Deployments, for Informational
Nov 2007	Submit final doc on Route Optimization Needs for Automobile and Highway Deployments, for Informational
Nov 2007	Submit final doc on Route Optimization needs for Personal Mobile Router, for Informational
Dec 2007	Determine how to proceed with remaining automotive/Personal Mobile Router solutions
Dec 2007	Recharter to work on the remaining automotive/Personal Mobile Router solutions
Dec 2007	Submit I-D 'Mobile IPv6 Experimental Allocations' to IESG for publication as a Proposed Standard.
Dec 2007	Submit the I-D 'RADIUS Mobile IPv6 Support' to IESG for publication as a proposed standard.
Dec 2007	Submit the final doc on MIB for NEMO Basic Support to the IESG, for Proposed Standard
Dec 2007	Submit the final doc on Prefix Delegation for NEMO to the IESG, for Proposed Standard
Feb 2008	Submit final doc for solution to aircraft/spacecraft problem to the IESG, for Proposed Standard
Feb 2008	Submit I-D 'Mobile IPv6 Operation with Firewalls' to IESG for publication as Informational.
Feb 2008	Submit I-D(s) related to specific updates and corrections of RFC 3775 to IESG for publication as Proposed Standard. 
Mar 2008	Submit Flow/binding policies exchange to IESG

_______________________________________________
Mip6 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mip6

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 18 Jun 2007 16:55:21 -0700

The charter looks good. A few comments.

The charter is missing RADIUS Mobile IPv6 support (it is listed
in the milestones). The deployment considerations for Mobile
IPv6 should talk about extensions to interwork with a AAA
infrastructure.

> specifications consist of:

Suggest replacing 3776 with 4877 or add 4877. 4877 updates 3776.

> mobile nodes (A.2), mechanisms to support high-availabity home agents

typo. It should be "availability".

>       analyzed and addressed relates to multilink subnets.

Based on the discussions I have had so far (online and offline), I
don't think there is an issue with multilink subnets in MIPv6. We
could have a specific deliverable which explains how MIPv6 treats
tunnels to each mobile node as being as extension of the home link.

> Sep 2007        Submit I-D 'Mobility Header Home Agent Switch Message' 
> to IESG for publication as a Proposed Standard.
> Sep 2007        Submit Analysis of the use of Multiple Simultaneous 
> Care-of Addresses and Home Agent addresses in Mobile IPv6
> Nov 2007        Submit final doc on Route Optimization Needs for 
> Aircraft and Spacecraft Deployments, for Informational
> Nov 2007        Submit final doc on Route Optimization Needs for 
> Automobile and Highway Deployments, for Informational
> Nov 2007        Submit final doc on Route Optimization needs for 
> Personal Mobile Router, for Informational
> Dec 2007        Determine how to proceed with remaining 
> automotive/Personal Mobile Router solutions
> Dec 2007        Submit I-D 'Mobile IPv6 Experimental Allocations' to 
> IESG for publication as a Proposed Standard.
> Feb 2008        Submit final doc for solution to aircraft/spacecraft 
> problem to the IESG, for Proposed Standard
> Feb 2008        Submit I-D(s) related to specific updates and 
> corrections of RFC 3775 to IESG for publication as Proposed Standard.

For many months there are at least three specifications being sent
to the IESG. In September, there are five. Might be a big ambitious.

Vijay

---

From: "Benjamin Lim" <[email-masked]>
Date: Tue, 19 Jun 2007 10:32:38 +0800

Hi,

I snip points for comments.

[snip] from (A.3) Use of multiple interfaces.
>       generalized approach to cater for multiple prefixes available to
[/snip]

[snip] from (A.5) Route optimization of network mobility.
>       of NEMO networks....
[/snip]

I feel that there is a conflict between A.3 and A.5. From my interpretation,
A.3 mentions that the WG will consider multi-homing w.r.t multiple
interfaces for mobile host/routers. However, in A.5, it is said that WG will
NOT consider multi-homing that are not related to NEMO. Suggest removing the
restriction of multi-homing consideration from A.5.

Regards,
Benjamin Lim

---

From: "Hesham Soliman" <[email-masked]>
Date: Tue, 19 Jun 2007 14:25:42 +1000

Hi Jari, 

Thanks for this, some comments inline, mainly editorial.  

 > rationale documents or description of specific issues within the

=> I would list those in bullet format for clarity by placing (A), (B)..et
first then the text describing it. Same for the text below.

 > (A.4). 

  In addition, there are specific needs of the automotive and
 > aviation communities with regards to route optimization of network

=> I'd reword the above to say:
Address the specific needs of automotive and aviation communities for route
optimisation in nemo.

 >       be taken offline for maintenance.

=> s/may need/needs

 >       been implemented and tested.

=> Reword: Today, the protocols do not provide suppport...

 >       and modification of multiple simultaneous tunnels.

=> The monami work was focused on the multiple CoA scenarios and explicitly
removed the multiple HoA scenarios as a condition of the WG starting. We
might need to discuss the impact of adding that back on the amount of work,
overlap with site multihoming ...etc.

 >         Care-of Address and Home Agent address [Standard Track].

=> We discussed, online and offline the possibility of having two drafts
here, one specifying the protocol (transport) and one defining the format
for the flow descriptors. Are we now merging them into one? 

 >       firewalls cause as identified in RFC 4487.

=> Hmm. I have some doubts about the "work on a solution" part. We need to
assess those problems and decide whether a solution is needed. If needed
then we should produce one. We discussed these issues in the FW DT and it's
not clear, at least to me, that a solution is a certainty.

More to come, but these are my initial comments up to this part. 

Hesham

 > Aug 2007	Submit I-D 'Motivation for Authentication I-D' 
 > to IESG for publication as Informational.
 > Sep 2007	Submit I-D 'Mobility Header Home Agent Switch 
 > Message' to IESG for publication as a Proposed Standard.
 > Sep 2007	Submit Analysis of the use of Multiple 
 > Simultaneous Care-of Addresses and Home Agent addresses in 
 > Mobile IPv6
 > Sep 2007	Submit I-D 'Mobile IPv6 Dual-Stack Operation' 
 > Oct 2007	Submit I-D 'Mobile IPv6 Vendor Specific Option' 
 > to IESG for publication as a Proposed Standard
 > Nov 2007	Submit final doc on Route Optimization Needs 
 > for Aircraft and Spacecraft Deployments, for Informational
 > Nov 2007	Submit final doc on Route Optimization Needs 
 > for Automobile and Highway Deployments, for Informational
 > Nov 2007	Submit final doc on Route Optimization needs 
 > for Personal Mobile Router, for Informational
 > Dec 2007	Recharter to work on the remaining 
 > Dec 2007	Submit I-D 'Mobile IPv6 Experimental 
 > Allocations' to IESG for publication as a Proposed Standard.
 > Dec 2007	Submit the I-D 'RADIUS Mobile IPv6 Support' to 
 > IESG for publication as a proposed standard.
 > Dec 2007	Submit the final doc on MIB for NEMO Basic 
 > Support to the IESG, for Proposed Standard
 > Feb 2008	Submit final doc for solution to 
 > aircraft/spacecraft problem to the IESG, for Proposed Standard
 > Feb 2008	Submit I-D 'Mobile IPv6 Operation with 
 > Firewalls' to IESG for publication as Informational.

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 19 Jun 2007 11:02:08 +0200

> restriction of multi-homing consideration from A.5.

I agree, I had the same remark.  I think the text looks so because it's 
still in an initial phase of merging, and the NEMO text was written 
probably with only the NEMO WG in mind, not the merged group.

I agree removing that restriction on multihoming since MEXT _will_ work 
on multiple CoAs, multiple HAs, multiple interfaces, etc.

Alex

> Monami6 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/monami6
> 

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

---

From: Jari Arkko <[email-masked]>
Date: Tue, 19 Jun 2007 14:38:03 +0300

Vijay,

> IPv6 should talk about extensions to interwork with a AAA

Right. I added this.

> Suggest replacing 3776 with 4877 or add 4877. 4877 updates 3776.

Ah yes. I made the replacement.

> typo. It should be "availability".

Corrected.

> tunnels to each mobile node as being as extension of the home link.

Right. But your statement above is not in conflict with what
the charter says, i.e., its fine to analyze and document the
results of an analysis.

>> Oct 2007        Submit I-D 'Mobile IPv6 Vendor Specific Option' to
>> IESG for publication as a Proposed Standard

Ok, I felt that too but did not want to change to many of them
(I already postoned some).

But you are right, this needs to change.

Please find a new version attached:

Chair(s):
TBD

Internet Area Advisor:

Mailing Lists:
TBD

o RFC 3775
o RFC 3963
o RFC 4877

Deployment considerations call for solutions to enable dual-stack
operation (A.1), allow the use of multiple interfaces in mobile nodes
(A.2), mechanisms to support high-availability home agents (A.3), and
ways to employ Mobile IPv6 in the presence of firewalls (A.4). In
addition, there are specific needs of the automotive and aviation
communities with regards to route optimization of network mobility
(A.5). Finally, support for AAA is needed as a continuation of earlier
work on bootstrapping (A.6).

   

   

   

   

   

   

(A.6) Bootstrapping mechanisms developed earlier in the MIP6 WG
      require AAA support for Mobile IPv6. Part of this work is
      already being done in the DIME WG, but the MEXT WG is chartered
      to complete a design for RADIUS.

Goals and Milestones:

Jul 2007    Submit -00 draft on Route Optimization Needs for Aircraft
and Spacecraft Deployments
Jul 2007    Submit -00 draft on Route Optimization Needs for Automobile
and Highway Deployments
Jul 2007    Submit -00 draft on Route Optimization needs for Personal
Mobile Router
Aug 2007    Submit Multiple CoA Registration to IESG
Aug 2007    Submit I-D 'Motivation for Authentication I-D' to IESG for
publication as Informational.
Aug 2007    Submit I-D 'Goals for AAA HA Interface' to IESG for
publication as Informational.
Sep 2007    Submit I-D 'Mobility Header Home Agent Switch Message' to
IESG for publication as a Proposed Standard.
Sep 2007    Submit -00 draft for solution to aircraft/spacecraft problem
Sep 2007    Submit I-D 'Mobile IPv6 Dual-Stack Operation' to IESG for
publication as a Proposed Standard.
Oct 2007    Submit I-D 'Mobile IPv6 Vendor Specific Option' to IESG for
publication as a Proposed Standard
Nov 2007    Submit Multiple Interfaces Motivations and Scenario to IESG,
for Informational
Nov 2007    Submit final doc on Route Optimization Needs for Aircraft
and Spacecraft Deployments, for Informational
Nov 2007    Submit Analysis of the use of Multiple Simultaneous Care-of
Addresses and Home Agent addresses in Mobile IPv6
Dec 2007    Submit final doc on Route Optimization Needs for Automobile
and Highway Deployments, for Informational
Dec 2007    Submit final doc on Route Optimization needs for Personal
Mobile Router, for Informational
Dec 2007    Submit I-D 'Mobile IPv6 Experimental Allocations' to IESG
for publication as a Proposed Standard.
Dec 2007    Submit the final doc on Prefix Delegation for NEMO to the
IESG, for Proposed Standard
Dec 2007    Submit I-D 'Home agent reliability' to IESG for publication
as a Proposed Standard.
Jan 2008    Submit the I-D 'RADIUS Mobile IPv6 Support' to IESG for
publication as a proposed standard.
Jan 2008    Determine how to proceed with remaining automotive/Personal
Mobile Router solutions
Jan 2008    Recharter to work on the remaining automotive/Personal
Mobile Router solutions
Feb 2008    Submit the final doc on MIB for NEMO Basic Support to the
IESG, for Proposed Standard
Feb 2008    Submit I-D 'Mobile IPv6 Operation with Firewalls' to IESG
for publication as Informational.
Mar 2008    Submit final doc for solution to aircraft/spacecraft problem
to the IESG, for Proposed Standard
Mar 2008    Submit I-D(s) related to specific updates and corrections of
RFC 3775 to IESG for publication as Proposed Standard.
Mar 2008    Submit Flow/binding policies exchange to IESG

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 19 Jun 2007 07:34:52 -0700

Thanks. The changes look good to me.

Vijay

---

From: Jari Arkko <[email-masked]>
Date: Tue, 19 Jun 2007 18:18:44 +0300

Benjamin,

> restriction of multi-homing consideration from A.5.

Right. Thanks for catching this. I edited A.5 to remove the
restriction.

Jari

---

From: Jari Arkko <[email-masked]>
Date: Tue, 19 Jun 2007 18:35:52 +0300

Thanks for your comments, Hesham!

> first then the text describing it. Same for the text below.

Ok.

> Address the specific needs of automotive and aviation communities for route

Ok.

> => s/may need/needs

Changed.

> => Reword: Today, the protocols do not provide suppport...

Got it.

> overlap with site multihoming ...etc.

I did not change anything regarding this in the charter. I'd like to
avoid too much reworking the charters beyond the merge. Or
do you have a specific text suggestion?

> for the flow descriptors. Are we now merging them into one? 

No, this is just me forgetting to make that change. I did
it now, plus changed the milestones.

> not clear, at least to me, that a solution is a certainty.

Ok. But again, I don't want to hold a real rechartering discussion and most
of the work items should just stay, unless they either have been completed
or have something obviously wrong with them.

I do agree with your principle, though. It could be that we can leave the
text as is, and simply handle this as a part of the management of the
group.

New version:

Chair(s):
TBD

Internet Area Advisor:

Mailing Lists:
TBD

o RFC 3775
o RFC 3963
o RFC 4877

The primary goal of the MEXT working group will be to (A) enhance base
IPv6 mobility by continuing work on developments that are required for
wide-scale deployments and specific deployment scenarios.
Additionally, (B) the working group will ensure that any issues
identified by implementation and interoperability experience are
addressed, and that the base specifications are maintained. (C) The
group will also produce informational documentation, such as design
rationale documents or description of specific issues within the
protocol.

Deployment considerations call for (A.1) solutions to enable
dual-stack operation, (A.2) allowing the use of multiple interfaces in
mobile nodes, (A.3) mechanisms to support high-availability home
agents, (A.4) ways to employ Mobile IPv6 in the presence of firewalls,
(A.5) address the specific needs of automotive and aviation
communities for route optimisation in network mobility, and (A.6)
support for AAA is needed as a continuation of earlier work on
bootstrapping.

A mechanism to force an MN to switch the HA that is currently
serving it. This is required in deployments where the HA needs to
be taken offline for maintenance.

Today, the protocols do not provide suppport for simultaneous
differentiated use of multiple access technologies. Several
proposals exist for such support, and some of them have been
implemented and tested.

- A "Flow/binding policies exchange" solution for an exchange of
policies from the mobile host/router to the Home Agent and from the
Home Agent to the mobile host/router influencing the choice of the
Care-of Address and Home Agent address. The solution involves two
specifications, one for the policy format and another for its
transport [both Standard Track].

The WG will not consider routing issues inside the mobile
network. Existing routing protocols (including MANET protocols)
can be used to solve these problems. The group will also not
consider general route optimization, or other problems that are
not related to the deployment and maintenance of NEMO
networks. Similarly, the group will not consider or rely on the
results of general routing architecture, Internet architecture,
or identifier-locator split issues that are discussed in
separate, long term efforts elsewhere in the IETF. Finally, the
group will not consider solutions that require changes from
correspondent nodes in the general Internet

Goals and Milestones:

Jul 2007 Submit -00 draft on Route Optimization Needs for Aircraft and
Spacecraft Deployments
Jul 2007 Submit -00 draft on Route Optimization Needs for Automobile and
Highway Deployments
Jul 2007 Submit -00 draft on Route Optimization needs for Personal
Mobile Router
Aug 2007 Submit Multiple CoA Registration to IESG
Aug 2007 Submit I-D 'Motivation for Authentication I-D' to IESG for
publication as Informational.
Aug 2007 Submit I-D 'Goals for AAA HA Interface' to IESG for publication
as Informational.
Sep 2007 Submit I-D 'Mobility Header Home Agent Switch Message' to IESG
for publication as a Proposed Standard.
Sep 2007 Submit -00 draft for solution to aircraft/spacecraft problem
Sep 2007 Submit I-D 'Mobile IPv6 Dual-Stack Operation' to IESG for
publication as a Proposed Standard.
Oct 2007 Submit I-D 'Mobile IPv6 Vendor Specific Option' to IESG for
publication as a Proposed Standard
Nov 2007 Submit Multiple Interfaces Motivations and Scenario to IESG,
for Informational
Nov 2007 Submit final doc on Route Optimization Needs for Aircraft and
Spacecraft Deployments, for Informational
Nov 2007 Submit Analysis of the use of Multiple Simultaneous Care-of
Addresses and Home Agent addresses in Mobile IPv6
Dec 2007 Submit final doc on Route Optimization Needs for Automobile and
Highway Deployments, for Informational
Dec 2007 Submit final doc on Route Optimization needs for Personal
Mobile Router, for Informational
Dec 2007 Submit I-D 'Mobile IPv6 Experimental Allocations' to IESG for
publication as a Proposed Standard.
Dec 2007 Submit the final doc on Prefix Delegation for NEMO to the IESG,
for Proposed Standard
Dec 2007 Submit I-D 'Home agent reliability' to IESG for publication as
a Proposed Standard.
Jan 2008 Submit the I-D 'RADIUS Mobile IPv6 Support' to IESG for
publication as a proposed standard.
Jan 2008 Determine how to proceed with remaining automotive/Personal
Mobile Router solutions
Jan 2008 Recharter to work on the remaining automotive/Personal Mobile
Router solutions
Feb 2008 Submit the final doc on MIB for NEMO Basic Support to the IESG,
for Proposed Standard
Feb 2008 Submit I-D 'Mobile IPv6 Operation with Firewalls' to IESG for
publication as Informational.
Mar 2008 Submit final doc for solution to aircraft/spacecraft problem to
the IESG, for Proposed Standard
Mar 2008 Submit I-D(s) related to specific updates and corrections of
RFC 3775 to IESG for publication as Proposed Standard.
Mar 2008 Submit Flow/binding policy format to IESG, for Proposed Standard
Mar 2008 Submit Flow/binding policy transport to IESG, for Proposed Standard

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 19 Jun 2007 09:42:22 -0700

> text as is, and simply handle this as a part of the management of the

Well, there are issues. We have published a document on this.
http://www.ietf.org/rfc/rfc4487.txt

If we conclude that there is no need for specifying anything
new, we would at least need a BCP recommending some firewall
configuration for MIPv6.

Vijay

---

From: Christian Vogt <[email-masked]>
Date: Tue, 19 Jun 2007 22:22:09 +0300

>                                     [...]  The group will also not
>       networks. [...]

Jari, Benjamin, Alexandru,

shouldn't this be modified to something like the following sentence to
avoid conflicts with Shim6?

                                             The group will not
        consider general multi-homing problems that are not related to

        the deployment and maintenance of Mobile IPv6 or NEMO networks.
        The group will also not consider general route optimization, or
        other problems that are not related to the deployment and
        maintenance of NEMO networks.

Best,
- Christian

---

From: "Benjamin Lim" <[email-masked]>
Date: Wed, 20 Jun 2007 10:25:35 +0800

Hi Christian,

I agree that we should avoid conflicts with Shim6. My concern is that with
your proposed text is flow filtering for NEMO within scope of MEXT?

Regards,
Benjamin Lim

> -----Original Message-----
> From: Christian Vogt [mailto:[email-masked]]
> Sent: Wednesday, June 20, 2007 3:22 AM
> To: Jari Arkko; [email-masked];
[email-masked]
> Cc: 'Mobile IPv6 Mailing List'
> Subject: Re: [Mip6] Merged WG charter
>

---

From: "Hesham Soliman" <[email-masked]>
Date: Wed, 20 Jun 2007 14:22:31 +1000

> do you have a specific text suggestion?

=> Ok. If anything, I would associate the multiple HoA work with the
analysis document rather than the standards track work. But I get your
point, I agree that we should avoid reworking the charter at this point.

 > text as is, and simply handle this as a part of the management of the

=> Fine with me.
Below are comments on the rest of the charter. 

 > mobile, and communicate with peer NEMO networks/MNNs.

=> I find the association with speed a little misleading. After all, we only
care about the frequency of handovers and route optimisation, which don't
necessarily correlate with speed. It's  up to you to decide whether you
should keep it or remove it (not a huge issue) but at least in the above
text the Personal router case just doesn't fit as a separate bullet. If the
main distinction is speed then the Personal router case can fall under with
of the bullets above it.

 > personal mobile router solutions requires rechartering.

=> Again, the scope of the Personal router work sounds odd, but it's saved
by the last sentence. 

 > mechanism, the Authentication Protocol (RFC 4285).

=> I couldn't see the DSMIP work above but it's listed in the goals section.

That's all from me, thanks,
Hesham

 > Aircraft and

---

From: Christian Vogt <[email-masked]>
Date: Thu, 21 Jun 2007 09:35:26 +0300

> your proposed text is flow filtering for NEMO within scope of MEXT?

Yes, it is.  The text basically says that the WG will consider
multi-homing only for host/network mobility, but not beyond that.

Best,
- Christian

---

From: Jari Arkko <[email-masked]>
Date: Thu, 21 Jun 2007 11:06:45 +0300

Hesham,

> point, I agree that we should avoid reworking the charter at this point.

I think this is already in the text about the individual documents.

> main distinction is speed then the Personal router case can fall under with

I hear you, but this text comes from a compromise that I made with
the rest of the IESG to get the charter approved. I would rather have
that discussion again.

> => Again, the scope of the Personal router work sounds odd, but it's saved

Again, part of the same compromise.

> => I couldn't see the DSMIP work above but it's listed in the goals section.

There's protocol work in the goals section (A.1) and milestones. If you
are referring
to the problem definition document, it has already been submitted to the
IESG
and even approved, so there is no need to keep the informational document
in the charter anymore.

> That's all from me, thanks
>   
Thank you for your detailed review. It has helped a lot.

Jari

---

From: "Hesham Soliman" <[email-masked]>
Date: Thu, 21 Jun 2007 18:28:07 +1000

Hi Jari, 

Thanks for the response, I'm ok with this. 

Hesham 

 > From: Jari Arkko [mailto:[email-masked]] 
 > Sent: Thursday, June 21, 2007 6:07 PM
 > To: Hesham Soliman

---

From: Jari Arkko <[email-masked]>
Date: Thu, 21 Jun 2007 14:27:59 +0300

Christian,

>         maintenance of NEMO networks.

Yes, that's better. Thanks.

Jari

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 21 Jun 2007 14:23:45 +0200

Jari Arkko wrote:
[...]
> the rest of the IESG to get the charter approved. I would rather have

Not sure you prefer or not to re-discuss that again, sounds as if you 
don't(?)

If to be re-discussed: a classification of IP mobility protocols and 
mobile devices by the speed (time and distance) they physically move 
makes indeed some sense to me (flying aircraft:fast-speed/long-distance, 
wheeled vehicle:moderate-speed/local-distance and 
walk:slow-speed/micro-distance) but it would make more sense if we used 
it side-by-side with an IP-relevant definition and classificaiton of 
speed.  A mobile host moving at 130kmph is very fast and changing its 
address twice-per-hour is very slow - physical speed different than 
IP-relevant 'speed' for the same IP device.

Hesham mentioned 'frequency of handover' which could too be defined.

For PMR better fitting your classification: PMR doesn't move seen by 
LFN, so zero-speed/zero-distance.  But a personal area network PMR+LFN 
does move maybe as a slow-speed/local-distance (like automotive) or 
slower, as a walk-speed/nano-distance.

Finally, we should probably use PAN, LAN and MAN IEEE terminology too.

Alex

---

From: Jari Arkko <[email-masked]>
Date: Thu, 21 Jun 2007 15:33:16 +0300

Alexandru,

> Not sure you prefer or not to re-discuss that again, sounds as if you

Sorry, there was a crucial "not" word missing from
my e-mail. I don't want to discuss this again, because
that might mean having another lengthy discussion
at the IESG about it. We know what we need to do for
the NEMO RO, I think, so I would suggest we get on
with that...

Jari

---

From: Thierry Ernst <[email-masked]>
Date: Thu, 21 Jun 2007 17:37:19 +0200

Please replace (Mobile IPv6 and )"NEMO networks" with (Mobile IPv6 and)
"NEMO Basic Support protocols".

BTW, can't we set up a new mailing list quickly enough and move all the
discussion to that ML instead of splitting that discussion across
MIP6/NEMO/MonAmi6 ?

Thierry.

On Thu, 21 Jun 2007 14:27:59 +0300

-- 
Thierry ERNST, PhD 
INRIA Rocquencourt France Project-Team IMARA / JRU LARA
http://www.lara.prd.fr +33 1 39 63 59 30 (office)

---

From: Jari Arkko <[email-masked]>
Date: Thu, 21 Jun 2007 19:01:37 +0300

Makes sense, thanks. I will take care of these.

Jari