Subject: [Mip6] new charter proposal

From: Jari Arkko <[email-masked]>
Date: Sun, 02 Jul 2006 23:41:11 +0300

Here's a new charter proposal that the chairs and me have worked
on. We would like some list discussion on whether this meets the
group's expectations. There will also be a short slot in Montreal to
talk about it. As has been indicated earlier, this is not a general
re-charter for potential new work but rather a cleanup and
re-alignment to what is already being worked on.

Mobility for IPv6 (mip6)

Last Modified: 2006-07-02

Chair(s):
Basavaraj Patil <[email-masked]>
Gopal Dommety <[email-masked]>

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

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

Mailing Lists:
General Discussion: [email-masked]
To Subscribe: https://www.ietf.org/mailman/listinfo/mip6
Archive: http://www.ietf.org/mail-archive/web/mip6/index.html

Description of Working Group:

Mobile IPv6 (MIP6) 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 TCP
connections and UDP port bindings. The base specifications for Mobile
IPv6 consist of:

     o RFC 3775
     o RFC 3776

The primary goal of the MIP6 working group will be to enhance base
IPv6 mobility by continuing work on developments that are required for
wide-scale deployments. 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.

Deployment considerations call for work to reduce per-mobile node
configuration and enrollment effort, solutions to enable dual-stack
operation, mechanisms to support high-availabity home agents, and ways
to employ Mobile IPv6 in the presence of firewalls.

Work items related to base specification maintenance include:

 - Create and maintain an issue list that is generated on the basis of
   implementation and interoperability experience. Address specific
   issues with specific updates or revisions of the base
   specification.  This work relates only to corrections and
   clarifications. The working group shall not revisit design
   decisions or change the protocol.

 - Update RFC 3776 to specify the usage of IKEv2 for the establishment
   of the IPsec SA between the MN and HA. This work also provides a
   way for a mobile node to change its home address or employ multiple
   home addresses as needed.

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

Work items related to large scale deployment include:

 - Bootstrapping Mobile IPv6: A bootstrapping mechanism is intended to
   be used when the device is turned on the very first time and
   activates Mobile IPv6, or periodically such as when powering
   on. The WG should investigate and define the scope before solving
   the problem.

   Work on the problem statement and the solutions needed for various
   deployment scenarios.

 - Capture the AAA requirements needed for bootstrapping and
   deployment, and work with the Radext and DiME WGs on the solutions.

 - 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. This work will be done in collaboration with the
   NEMO WG.

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

 - Work on solutions to deal with firewalls and the problems that
   firewalls cause as identified in RFC 4487.

Work items related to informational documentation include:

 - Produce a problem statement relating to location privacy and the
   use of Mobile IPv6. Work with the IRTF MOBOPTS RG on developing the
   solution.

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

It should be noted that some of the features that are directly related
to Mobile IPv6 are being worked on in the MONAMI6, MIPSHOP, and NEMO
working groups. The specific extensions from these groups are out of
scope for the MIP6 working group. In particular, all optimizations are
out of scope. However, MIP6 may assist these groups when they use
features listed above and have requirements on them.

Milestones:

Done          Submit I-D 'MIPv6 operation with IKEV2 and the revised
        IPsec Architecture' to IESG for publication as a
        Proposed Standard.

Jul 2006    Submit I-D 'Motivation for Authentication I-D' to IESG
        for publication as Informational.

Aug 2006    Submit I-D 'Bootstrapping solution for Integrated Scenario'
        to IESG for publication as a Proposed Standard.

Aug 2006    Submit I-D 'Bootstrapping solution for split Scenario' to IESG
        for publication as a Proposed Standard.

Sep 2006    Submit I-D 'Goals for AAA HA Interface' to IESG for
        publication as Informational.

Nov 2006    Submit I-D 'Address Location Privacy and Mobile IPv6 Problem
        Statement' to IESG for publication as Informational.

Dec 2006    Submit I-D 'Home agent reliability' to IESG for publication
        as a Proposed Standard.

Dec 2006    Submit I-D 'Mobile IPv6 Experimental Allocations' to IESG for
        publication as a Proposed Standard.

Dec 2006    Submit I-D 'Mobile IPv6 Dual-Stack Operation' to IESG for
        publication as a Proposed Standard.

Apr 2007    Submit I-D 'Mobile IPv6 Operation with Firewalls' to IESG
        for publication as Informational.

May 2007    Submit I-D(s) related to specific updates and corrections
        of RFC 3775 to IESG for publication as Proposed Standard.

Note that there is one missing piece in the above: draft-ietf-mip6-cn-ipsec.
I would like to shepherd that through as an info/exp document instead
of incorporating it in the charter above. One reason for that is that
its ready and I can take it forward, but I generally want to avoid
making alternate designs Proposed Standard unless we have some
significant reasons for doing otherwise. But I'll listen to the group's
input on this too.

--Jari

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

---

From: "Alper Yegin" <[email-masked]>
Date: Sun, 2 Jul 2006 22:35:27 -0700

Hi Jari,

Assuming the group will decide to progress the draft-jang-mip6-hiopt-00.txt
as a standalone document, would you suggest we take it up in the MIP6 WG or
the DHC WG?

Alper

> -----Original Message-----
> From: Jari Arkko [mailto:[email-masked]]
> Sent: Sunday, July 02, 2006 1:41 PM
> To: Mobile IPv6 Mailing List
> Cc: Gopal Dommety; Basavaraj Patil
> Subject: [Mip6] new charter proposal
> 
>

---

From: Jari Arkko <[email-masked]>
Date: Mon, 03 Jul 2006 08:49:49 +0300

>as a standalone document, would you suggest we take it up in the MIP6 WG or
First: there's a work item in the proposed charter for bootstrapping
work. Depending on what makes sense to the group and chairs you
can break it up in multiple drafts if you want to. Charters or milestone
lists do not normally prevent you from doing that.

And the charter language on bootstrapping also allows you to
design the protocol mechanisms that you think you need.

As for the specific working group, we are trying to follow a model
where the DHCP-using WG is responsible for the actual document, but
that there is review from the DHC working group. For instance,
a parallel WGLC in both groups. This model makes the group with
specific application knowledge responsible on what they want to
do, and DHC responsible for ensuring that you are not breaking
DHCP.

--Jari

---

From: "Gerardo Giaretta" <[email-masked]>
Date: Tue, 4 Jul 2006 17:38:26 +0200

Hi Jari,

thanks for providing the charter proposal. One question: is there any
plan to produce docs on bootstrapping of rfc4285?

In the charter proposal it is mentioned that the rationale behind
rfc4285 will be produced. Are we going to take a step forward and
specify bootstrapping mechanisms also for rfc4285? Or are they
considered specific of SDOs that are using rfc4285 (i.e. WiMAX Forum,
3GPP2) and therefore not standardized in IETF?

--Gerardo

---

From: Jari Arkko <[email-masked]>
Date: Tue, 04 Jul 2006 21:03:07 +0300

Hi Gerardo,

> specify bootstrapping mechanisms also for rfc4285? 

The design rationale was really a separate thing. The version
of the charter that I posted does not include coverage of RFC
4285 in other ways.

But its a good question what the scope of the bootstrapping
work should be. What does the working group think? How
did we define it in the problem statement?

Ideally, I would not like to see that RFC 4285 causes divergent
solutions for every other part of the technology along with it. Can
we design our DHCP options and AAA interfaces so that they
don't care whether its IKEv2 or authentication option at the
bottom?

--Jari

---

From: "Jean-Michel Combes" <[email-masked]>
Date: Wed, 5 Jul 2006 13:39:50 +0200

Hi Jari,

> re-alignment to what is already being worked on.

[snip]

> significant reasons for doing otherwise.

IMO, the draft-ietf-mip6-cn-ipsec should become Proposed Standard. The
main reasons are :
- No heavy modifications in the MIPv6 implementation (in fact, just to
be able to desactivate the RR mechanism)
- To have a mechanism that allows a strong security for RO

Thanks.

Best regards.

JMC.

> But I'll listen to the group's
> input on this too.
>
> --Jari
>
>

---

From: "Soliman, Hesham" <[email-masked]>
Date: Wed, 5 Jul 2006 05:17:02 -0700

Hi Jari, 

I didn't see a specific mention of:

http://www.ietf.org/internet-drafts/draft-ietf-mip6-dsmip-problem-02.txt

It's in the current charter. Is this covered under the DSMIP work
anyway? It's been ready for WGLC for a while. 

Hesham

---

From: Jari Arkko <[email-masked]>
Date: Wed, 05 Jul 2006 15:28:03 +0300

Soliman, Hesham wrote:

>anyway?
Good question. I wouldn't mind having a problem statement document
too if the group wants that. Question: there's a brief description of
the problem/motivation/scope/scenarios in the beginning of the
solution draft. Is that insufficient?

--Jari

---

From: "Soliman, Hesham" <[email-masked]>
Date: Wed, 5 Jul 2006 05:33:24 -0700

> solution draft. Is that insufficient?

=> Depends on who you ask :). Given the amount of questions that we
continue to get about the problem and why this is needed I would think
it's insufficient. I think this will be a good document to point people
to when these issues come up. Thomas just asked for the same thing
recently on the list. So I think it's helpful to have it. 

Hesham

---

From: "Gerardo Giaretta" <[email-masked]>
Date: Wed, 5 Jul 2006 14:12:50 +0200

> did we define it in the problem statement?

The problem statement is mainly focused on IPsec SA between MN and HA.
Also some references to rfc4285 have been deleted during IESG
discussio based on Sam's comments.

> don't care whether its IKEv2 or authentication option at the

I guess yes. I think that at least HA discovery defined using DNS and
DHCP can be applied even in case rfc4285. Some more thoughts are
needed for HoA assignment, since so far it is specified for IKEv2, at
least in split scenario.

Obviously the way the SA is set up is different if either IPsec or
rfc4285 are used.

The question is: are the SDOs that have pushed for rfc4285 interested
in a bootstrapping solution developed in IETF?

--Gerardo

---

From: Jari Arkko <[email-masked]>
Date: Wed, 05 Jul 2006 15:57:41 +0300

> in a bootstrapping solution developed in IETF?

That is indeed a relevant question.

--Jari

---

From: Jari Arkko <[email-masked]>
Date: Wed, 05 Jul 2006 16:31:25 +0300

> - To have a mechanism that allows a strong security for RO

Thanks for the input.

(Just to explain my viewpoint:  What you say above is not by itself a
sufficient reason for a Proposed Standard designation. The standards
track series exists as IETF's recommendation of what protocols we
believe should be employed. This recommendation is not just about
the technical feasibility and properties of the solution. We also need
to think about how many features implementations will have. We
need to think about interoperability, practical configuration feasibility,
applicability to different situations, expectations of what gets really
deployed, etc. My evaluation of the situation is that this is an
interesting tool for some situations, certainly worth documenting,
but not quite general enough to be a PS. It is also substantially
easier to publish Experimental RFCs; if deployment experience
shows that its great we could easily revisit the standards
track designation decision later.)

--Jari

---

From: "Jean-Michel Combes" <[email-masked]>
Date: Wed, 5 Jul 2006 15:59:09 +0200

Hi again,

2006/7/5, Jari Arkko <[email-masked]>:
> believe should be employed.

IMO, if an operator will want to deploy a MIPv6 based service allowing
RO, he will employ one with strong security especially if this
provided service is not free.
Indeed, like customer, will you accept to pay for a service knowing
that the operator will not be able to garantee the security?
Moreover, do you think that a operator will accept to sully its
reputation in providing a weak security based service?
Clearly, a strong security mechanism is needed and IETF has to recommend one.

> This recommendation is not just about
> need to think about interoperability,

IPsec is mandatory in IPv6.

>  practical configuration feasibility,

IPsec/IKE are RFC and already implemented and used.

> applicability to different situations,

One MN and one CN can already set IPsec connexions between them after
the use of RR.

>  expectations of what gets really
> deployed,

I wrote above what is my feeling about deployment.

> etc. My evaluation of the situation is that this is an

I hope you understand my point of view and my fears.

Thanks.

Best regards.

JMC.

---

From: Rajeev Koodli <[email-masked]>
Date: Wed, 05 Jul 2006 11:06:05 -0700

Hi Jari,

>        Statement' to IESG for publication as Informational.
The ID went through WG LC; I have incorporated the comments.
I think we can send this to IESG by September (taking remaining 
discussion into
consideration).

-Rajeev

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 05 Jul 2006 12:38:47 -0700

> recently on the list. So I think it's helpful to have it. 

there is an issue here. I understand MIPv6 WG working on
a problem statement to justify DS-MIPv6. but I don't see
the point in MIPv6 WG justifying the need for DS-MIPv4.
perhaps the problem statement for DS-MIPv4 should be done
in the MIP4 WG (if at all MIP4 WG does DS-MIPv4).

Vijay

---

From: Jari Arkko <[email-masked]>
Date: Wed, 05 Jul 2006 23:40:09 +0300

> I think we can send this to IESG by September (taking remaining

Ok.

--Jari

---

From: Francis Dupont <[email-masked]>
Date: Wed, 05 Jul 2006 23:07:47 +0200

In your previous mail you wrote:

   > We need to think about interoperability, ...

=> BTW I implemented it (as the main part was to adapt the MIPv6 MN
automaton to alternative to RR it should be easy to port to IKEv2 /
racoon2).

Regards

[email-masked]

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 05 Jul 2006 15:57:14 -0700

> That is indeed a relevant question.

I saw a bunch of hacks in SDOs like 3GPP2 and Wimax that
are adopting RFC 4285. that was one of the reasons, I
wrote up
http://www.ietf.org/internet-drafts/draft-devarapalli-mip6-authprotocol-bootstrap-01.txt
this will work with both DNS and DHCP based HA discovery.
it mainly describes HoA configuration and SA setup.

personally, I think IKEv2 and IPsec should be used for
MIPv6 (I spent some effort in advocating this in 3GPP2).
but since the SDOs seem to prefer RFC 4285, I would
rather have them use a bootstrapping solution for RFC
4285 that is standardized in the IETF.

also I think SDOs sometimes try to avoid creating an
IETF dependency for obvious reasons. :)

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 05 Jul 2006 16:34:29 -0700

> - To have a mechanism that allows a strong security for RO

if this were possible, we would have had MIPv6 standardized back
in 2000-2001. I remember Jeff Schiller blasting us in December
2000 for assuming trust between the MN and the CN to be out of
scope. this is exactly what draft-ietf-mip6-cn-ipsec assumes.

then we had to design the return routability mechanism.

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 05 Jul 2006 15:48:11 -0700

> solution draft. Is that insufficient?

FWIW, I think the problem description in
draft-ietf-mip6-nemo-v4traversal-02.txt is sufficient.

Vijay

---

From: "Jean-Michel Combes" <[email-masked]>
Date: Thu, 6 Jul 2006 02:27:30 +0200

Hi Vijay,

the main reason was that protocols standardized in the IETF had to be
independent from the architecture. Today, I am not sure that is still
true (i.e. too many dependencies regarding where and how the protocols
are deployed, and today, some 'recent' RFC are architecture
dependent). But this is another debate ;)

To come back to your comment, it is true that trust between MN and CN
is needed for draft-ietf-mip6-cn-ipsec but if we have such one, shall
we put away a technical solution from IETF standardization?

Best regards.

JMC.

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 05 Jul 2006 17:31:43 -0700

> we put away a technical solution from IETF standardization?

note that I am not opposed to standardizing
draft-ietf-mip6-cn-ipsec. my email was in response to
your comment about cn-ipsec being stronger than return
routability. my main point is that they assume different
security models.

Vijay

---

From: "Soliman, Hesham" <[email-masked]>
Date: Thu, 6 Jul 2006 01:34:26 -0700

> the point in MIPv6 WG justifying the need for DS-MIPv4.

=> The nature of the problem is that it is specific to MIP. We don't,
AFAICS, get specific about v4 or v6 in describing the problem in
general. The results were two separate work items in the two different
groups. So a general problem statement, but specific solutions in WGs.

Hesham

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 06 Jul 2006 12:04:20 -0700

Francis Dupont wrote:
> => Vijay, it seems you are trying to break an open door: if the
> cn-ipsec is stronger than return routability, it is because
> it assume a different (and narrower) security model...

I guess we agree. since they assume different security models
we can't claim one is better than the other.

Vijay

---

From: Francis Dupont <[email-masked]>
Date: Thu, 06 Jul 2006 19:33:41 +0200

Regards

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 10 Jul 2006 01:52:02 +0200

Jari Arkko wrote:
> Hi Gerardo,
> 
>> thanks for providing the charter proposal. One question: is there
>> any plan to produce docs on bootstrapping of rfc4285?
>> 
> The design rationale was really a separate thing. The version of the
> charter that I posted does not include coverage of RFC 4285 in other
> ways.
> 
> But its a good question what the scope of the bootstrapping work
> should be. What does the working group think? How did we define it in
> the problem statement?

I think the current bootstrapping text in the proposed Charter leaves
place for bootstrapping for/with rfc4285 (auth for MIP6).  I think the
current text is not limited to the drafts split or integrated.

I also continue to think that a bootstrapping HA address/HoA  with 
DHAAD+MPD (not based on DNS nor DHCP) makes sense and may be accomodated 
by proposed Charter text.

> we design our DHCP options and AAA interfaces so that they don't care
> whether its IKEv2 or authentication option at the bottom?

Sounds a logical suggestion.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 10 Jul 2006 01:56:43 +0200

Soliman, Hesham wrote:
>> too if the group wants that. Question: there's a brief description
>> of the problem/motivation/scope/scenarios in the beginning of the 
> continue to get about the problem and why this is needed I would
> think it's insufficient. I think this will be a good document to
> point people to when these issues come up. Thomas just asked for the
> same thing recently on the list. So I think it's helpful to have it.
> 
Could it contain the problem statement from draft-wakikawa and from the
scenarios draft?

The only problem in draft-dsmip-problem that the reader is left with is
that it is inefficient to have both MIP4 and MIP6 running on the mobile.
  I don't think it is.  Draft-wakikawa has some wording on multiple
encapsulation as a problem, which makes more sense to me, IMHO.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 10 Jul 2006 02:09:24 +0200

Vijay Devarapalli wrote:
> Jari Arkko wrote:
>> Soliman, Hesham wrote:
>> 
>>> Hi Jari, I didn't see a specific mention of:
>>> 

Which section please?  I can't seem to find one.

Or you mean draft-ietf-mip6-dsmip-problem-02.txt?  That which lists
problems "implementation burdens", "operational burdens", "mm
inefficiencies" and "impossibility of maintaining IP connectivity".

Alex