Subject: RE: [MEXT] MEXT charter

From: Jari Arkko <[email-masked]>
Date: Tue, 20 Nov 2007 00:31:35 +0200

X-Spam-ScoFrom [email-masked] Mon Nov 19 17:31:40 2007
Date: Tue, 20 Nov 2007 00:31:25 +0200
From: Jari Arkko <[email-masked]>
To: [email-masked], Julien Laganier <[email-masked]>, 
	marcelo bagnulo braun <[email-masked]>
Cc: "Kniveton Timothy \(Nokia-ES/MtView\)" <[email-masked]>
Subject: [MEXT] MEXT starts now

Hi all,

I'm happy to announce that MEXT is now finally created. Marcelo
Braun and Julien Laganier are the new chairs. Please join me
in welcoming them and thanking them for taking up this task!

Their first task is to organize the agenda and meeting in
Vancouver, so send mail to them for agenda slots and other
requests.

The IETF secretary is working on the WG web page updates and
other practical details. The two slots for MIP6 in the current
agenda will be renamed to MEXT slots.

I would also like to thank the chairs of the three WGs that will
now be merged into one: Thierry, Gopal, Basavaraj, TJ, and
Nicolas  -- big thanks for your hard work over the years!

Jari Arkko

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

---

From: "Sri Gundavelli" <[email-masked]>
Date: Thu, 22 Nov 2007 12:02:49 -0800

This is a WG document and I thought this was in the charter and does
not require a charter update.

https://www.ietf.org/internet-drafts/draft-ietf-mip6-generic-notification-me
ssage-00.txt

Sri

> -----Original Message-----
> From: Jari Arkko [mailto:[email-masked]] 
> Sent: Monday, November 19, 2007 2:32 PM
> To: [email-masked]
> Subject: [MEXT] MEXT charter
> 
> 
> The charter that I sent to the secretary is shown below. I've
> updated the milestones plus taken some of the editorial
> comments from Thierry and Nicolas into account. However,
> I did not want to make any bigger changes due to the discussion
> we had with them in Chicago, because that would require a
> new IESG approval. But I note that given the interest for
> binding revocation, a charter update will probably be
> needed soon anyway. We can take care of remaining issues
> there.
> 
> ----
> 
> Mobility EXTensions for IPv6 (MEXT)
> 
> 
> Mailing Lists:
> http://www1.ietf.org/mail-archive/web/mext/current/index.html
> 
> 
> 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)
> 
> The MEXT Working Group continues the work of the former MIP6, NEMO,
> and MONAMI6 Working Groups.
> 
> The primary goal of MEXT 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) mechanisms to support high-availability
> home agents, (A.3) allowing the use of multiple interfaces in mobile
> nodes, (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.
> 
> Work items related to large scale deployment include:
> 
> (A.1) A Solution for Mobile IPv6 and NEMO 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 Mobile IPv6 or NEMO capable dual-stack hosts.
> 
> (A.2) A protocol based solution for enhancing the reliability of home
>       agents and a method to force a host/router 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 needs to
>       be taken offline for maintenance.
> 
> (A.3) Use of multiple interfaces.
> 
>       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.
>   
>       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 uses existing tunneling mechanisms defined for Mobile
>       IPv6. The involved nodes need to select which tunnel instance
>       to use when multiple ones are available due to multiple
>       addresses on either end. But the WG does not plan to define a
>       new mechanism for this, but rather 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. The solution 
> involves two
>         specifications, one for the policy format and another for its
>         transport [both 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 Basic Support nodes
>       and nodes served by them.
>   
>       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 extensions to routing protocols. The
>       group will not consider general multi-homing problems that are
>       not related to the deployment and maintenance of Mobile IPv6 or
>       NEMO Basic Support protocols. The group will also not consider
>       general route optimization, or other problems that are not
>       related to the deployment and maintenance of NEMO Basic Support
>       protocols. 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
> 
> (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.
> 
> 
> 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).
> 
> The group employs IPsec and IKE as a security mechanism. The group
> shall refrain, however, from making generic extensions to these
> protocols. Any proposed extension must be reviewed by the ADs
> before it can be accepted as a part of a work item.
> 
> 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 'Mobility Header Home Agent Switch Message' to
> IESG for publication as a Proposed Standard.
> 
> Dec 2007    Submit Multiple CoA Registration to IESG
> Dec 2007    Submit I-D 'Motivation for Authentication I-D' to IESG for
> publication as Informational.
> Dec 2007    Submit I-D 'Mobile IPv6 Dual-Stack Operation' to IESG for
> publication as a Proposed Standard.
> 
> Feb 2008    Submit -00 draft on Route Optimization Needs for Aircraft
> and Spacecraft Deployments
> Feb 2008    Submit -00 draft on Route Optimization Needs for 
> Automobile
> and Highway Deployments
> Feb 2008    Submit -00 draft on Route Optimization needs for Personal
> Mobile Router
> Feb 2008    Submit I-D 'Goals for AAA HA Interface' to IESG for
> publication as Informational.
> 
> Mar 2008    Submit the final doc on Prefix Delegation for NEMO to the
> IESG, for Proposed Standard
> 
> May 2008    Submit -00 draft for solution to 
> aircraft/spacecraft problem
> May 2008    Submit final doc on Route Optimization Needs for Aircraft
> and Spacecraft Deployments, for Informational
> May 2008    Submit final doc on Route Optimization Needs for 
> Automobile
> and Highway Deployments, for Informational
> May 2008    Submit final doc on Route Optimization needs for Personal
> Mobile Router, for Informational
> 
> Jun 2008    Submit the I-D 'RADIUS Mobile IPv6 Support' to IESG for
> publication as a proposed standard.
> Jun 2008    Determine how to proceed with remaining 
> automotive/Personal
> Mobile Router solutions
> 
> Jul 2008    Submit Multiple Interfaces Motivations and 
> Scenario to IESG,
> for Informational
> Jul 2008    Submit Analysis of the use of Multiple 
> Simultaneous Care-of
> Addresses and Home Agent addresses, for Informational
> 
> Aug 2008    Submit the final doc on MIB for NEMO Basic Support to the
> IESG, for Proposed Standard
> Aug 2008    Submit I-D 'Mobile IPv6 Operation with Firewalls' to IESG
> for publication as Informational.
> 
> Oct 2008    Submit Flow/binding policy format to IESG, for 
> Proposed Standard
> Oct 2008    Submit Flow/binding policy transport to IESG, for Proposed
> Standard
> 
> Nov 2008    Submit final doc for solution to 
> aircraft/spacecraft problem
> to the IESG, for Proposed Standard
> Nov 2008    Recharter to work on the remaining automotive/Personal
> Mobile Router solutions
> 
> Dec 2008    Submit I-D(s) related to specific updates and 
> corrections of
> RFC 3775 to IESG for publication as Proposed Standard.
> Dec 2008    Submit I-D 'Home agent reliability' to IESG for 
> publication
> as a Proposed Standard.
> 
>

---

From: "George Tsirtsis" <[email-masked]>
Date: Mon, 26 Nov 2007 08:16:39 +0000

Hi Sri,

According to this draft the sender of the notification message can resend
the notification if it sets the A flag and does not receive an ack. This is
correctly defined as a MAY, but I think some language should also be added
WRT the fact that lack of acknowledgement could also mean that the receiver
does not support generic notifications as all; or is some other behavior
expected in such a case?

Thanks
George

---

From: Sri Gundavelli <[email-masked]>
Date: Mon, 26 Nov 2007 09:37:08 -0800 (PST)

Hi George,

> does not support generic notifications as all; or is some other behavior

Thanks for the comment.

I agree, we need to provide the hint to the sender that the
receiver may not support this option and the suggested action.

Regards
Sri

---

From: Brian Haley <[email-masked]>
Date: Thu, 29 Nov 2007 11:49:33 -0500

Hi Sri and George,

> receiver may not support this option and the suggested action.

If the target node doesn't support the Generic Notification message, it 
should have generated a Binding Error, from Section 4:

    If the packet is dropped due to the above tests, the receiving node
    MUST follow the processing rules as Section 9.2 of [2].  For example,
    it MUST send a Binding Error message with the Status field set to 2
    (unrecognized MH Type value) if it does not support the message type.

How about we add this to the retransmission section, just to make that 
clear:

"If the sender of the Generic Notification Request message received a 
Binding Error with the Status field set to 2 (unrecognized MH Type 
value) in response to the original transmission, it MUST NOT retransmit 
the message since the receiver does not know how to process it."

-Brian