Subject: [MEXT] New items for the mext charter discussion

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 29 Nov 2007 12:55:41 +0100

Hi,

After the call for new work to be considered for mext, we have  
received a set of items to be considered, that we need to discuss.

MEXT is likely to recharter and add new items to the charter, but our  
energy is limited so we need to prioritize and decide what items are  
the most relevant to be included in the charter, since it seems hard  
to have energy to deal with all of them

So we would like to ask the WG to comment on the proposed items (or  
other items) and explain if they think that we should be investing  
effort on them. In order to evaluate these items, we should  
understand how important is to work on these items to foster the  
adoption and the deployment of MIPv6 and NEMO protocols.

So at this point, the discussion is two-folded: on one hand we would  
like to foster high level discussion on what is needed to foster  
mobility protocols deployment and in particular to relate this  
discussion with the items that have been proposed so far, and if  
needed propose new items for the charter.

It should be noted that at this point silence does not means  
acceptance of the proposed items and that a strong case for adopting  
new work is needed, since we need to focus our energy in critical  
items needed for protocol deployment.

------------------------------------------------------------------------ 
-------

New items proposed so far:

- Binding Revocation Mechanism for IPv6 Mobility

Define a generic binding revocation mechanism for Mobile IPv6
and its extensions (e.g. NEMO, Monami6, NETLMM). The
mechanism can be used by any mobility entity that provides
Mobile IP services to a MN (e.g. a
MIPv6 HA, a NETLMM LMA) to inform the MN itself or another
mobility entity that is involved in providing Mobile IP
services to the MN (e.g. a NETLMM MAG) of the termination of
either one, multiple or all bindings for a mobile node. The
mechanism should also allow any mobility entity (e.g. NETLMM
MAG or LMA) to signal the termination of bindings for
multiple mobile nodes via use of a single revocation message.

- MIPv6 home link operation in various SDOs

Many SDOs are considering the use of point-to-point links
between the mobile node and the home agent as a home link for
Mobile IPv6 to avoid the tunneling overhead. Some of these
point-to-point links do not support running neighbor discovery.
Attaching to the home link and returning to the home procedures
need to be analyzed for these point-to-point links, possible
with the use of binding update and binding acknowledgment
messages.

- IP Tunneling Optimization in a Mobile Environment

The widespread use of different forms of IP tunneling mechanisms in  
mobile environment, e.g., MIPv6,
HMIPv6, PMIPv6, has a negative impact on the protocol efficiency  
which is translated in the data packet
size, bandwidth usage and battery power consumption. Therefore, a  
mechanism which enables removing
the extra header would benefit the mobile node and optimize the  
bandwidth usage.

- Generic Notification Message for Mobile IPv6

A proposal for defining generic notification framework that can be  
used by the mobility
entities for sending and receiving asynchronous notification messages  
was proposed and
the same was adopted by the WG.

- GRE requirements for IPv6 mobility

   A proposal has been made for the use of GRE tunneling mechanism in  
Mobile IPv6. The GRE
   tunneling support exists in Mobile IPv4 and the proposal is for  
extending that functional
   capability to Mobile IPv6. Noted uses cases include the ability to  
carry any type of
   protocol payload in a generic header, the rich GRE header  
semantics allowing the exposure
   of a service identifier, such as a key that can be used by the  
tunnel endpoints for differential
   treatment of the carried payload and additionally supported by  
other use cases.

- 4283bis

Revised RFC 4283 to extend the subtype field in the Mobile Node
identifier option to include other identifiers like IEEE 802 MAC
address. The only subtype currently reserved is NAI. This may
not be sufficient for all scenarios.

- Bootstrapping mechanisms for using RFC 4285 with Mobile IPv6

Existing bootstrapping mechanisms for Mobile IPv6 only address
the use of IKEv2/IPsec for protecting Mobile IPv6 signaling
messages. Bootstrapping a home address and security associations
when RFC 4285 is used are not addressed. This draft describes
bootstrapping mechanisms for using RFC 4285 with Mobile IPv6.

- Interfacing between IKEv2/IPsec & MIPv6 by simple PF_KEY extensions

Work on the solution of interface, by which IKEv2 could get the
information from MIPv6 and negotiate or update right IPsec security
associations for MIPv6 when MN bootstrap in foreign network or
handover to new foreign network.

- RFC 3775 update

Revise RFC 3775 to fix minor issues and add clarifying test for
issues identified since it was published. The update would be
limited to minor changes and not include any major modifications
to the protocol.

- Additional NEMO global deployment tools

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

---

From: "Hesham Soliman" <[email-masked]>
Date: Thu, 29 Nov 2007 23:07:05 +1000

A few comments

 > multiple mobile nodes via use of a single revocation message.

=> I think this is quite simple and useful feature to have.

 > the extra header would benefit the mobile node and optimize the  

=> I think this is an extremely useful optimisation for several aspects of
MIPv6, not only HMIP and PMIP but it also reduces one of the nasty things
about lack of nemo RO. I'm strongly in favour of this. The double header
(sometimes triple) has been an obstacle with other SDOs as well when MIPv6
was considered.

 > the same was adopted by the WG.

=> Neutral. I don't think it's as important as the above.

 >    treatment of the carried payload and additionally supported by  

=> This is not important IMO and can easily have a lower priority. GRE and
IPv6 in general is not a high priority issue AFAICS. 

 > not be sufficient for all scenarios.

=> Neutral.

 > handover to new foreign network.

=> Not important IMO. We already have an IKE-based AAA solution.

 > limited to minor changes and not include any major modifications

=> This is certainly important but I still think it's early. Since this is
not something we'll do every year we should wait a bit more till there we
receive significant changes that need to be made.

Hesham

---

From: Basavaraj Patil <[email-masked]>
Date: Thu, 29 Nov 2007 15:17:35 -0600

Marcelo,

> the same was adopted by the WG.

This was already adopted by the MIP6 WG via consensus call and published as
a MIP6 WG document. Why revisit this discussion again?
I thought the MEXT charter would include all the WG I-Ds from MIP6, NEMO and
MONAMI6 to begin with.

-Raj

---

From: "Peng Yang" <[email-masked]>
Date: Fri, 30 Nov 2007 17:06:50 +0800

Hi, Hesham:

Please check the words in-line with [P.Y]
> >=> Not important IMO. We already have an IKE-based AAA solution.
[P.Y] I guess you are talking about IKEv2 getting MIP6 information (for
example: CoA) from AAA for SA negotiation. But when MN bootstrap in
foreign network, IKEv2 daemon in MN should get the CoA before the first
round-trip of IKE procedure. In this stage, the MIP6 information in AAA
is not accessible to MN. And, after handover, it's not so efficient to
update SA in MN/HA by this IKE-based AAA way, IMHO. 

Thanks a lot
P.Y

Disclaimer:
The contents of this e-mail, and its attachments, if any, are confidential and may be protected
by law against any unauthorized use.  If you have received this e-mail by mistake or have
reason to believe that you are not the intended recipient, please notify the sender by reply
e-mail as soon as possible and delete it from your computer system immediately thereafter.
If you are not the intended recipient, you must not copy this e-mail or attachment or disclose
the contents to any other person.  While we have made every effort to keep our network virus free,
we take no responsibility for any computer virus which might be transferred by way of this e-mail.

---

From: marcelo bagnulo braun <[email-masked]>
Date: Fri, 30 Nov 2007 12:27:26 +0100

Hi Vijay,

> I thought the MEXT charter would include all the WG I-Ds from MIP6,  

AFAIU, this is not included in the MEXT charter, so in order to work  
on this (or in any other work item), it must be included in the MEXT  
charter. So, if there is consensus in the WG that we should work on  
this, and the Ads are ok with it, we include it in the charter and we  
do it. But as long we don't have it in the charter, we as MEXT wg we  
cannot work on that.

hence, why this is in the charter discussion

(I don't know why this was not included in the MEXT charter in the  
first place though, but at this point, it seems that this is not part  
of the work MEXT is chartered to do)

Regards, marcelo

---

From: "Hesham Soliman" <[email-masked]>
Date: Sat, 1 Dec 2007 00:32:43 +1000

> round-trip of IKE procedure. 

=> I'm not sure what you mean by that. Of course any piece of networking SW
on the MN would need to know its address before it starts communicating. But
I don't see the relationship to this discussion.

   In this stage, the MIP6 
 > information in AAA

=> I'm sorry I can't follow. Have you looked at the IKEv2-based
bootstrapping work? It covers this scenario. 

Hesham