Subject: RE: [Dime] IETF#66 Meeting Minutes

From: Madjid Nakhjiri <[email-masked]>
Date: Fri, 04 Aug 2006 17:22:23 -0700

Was this minutes or 10-minutes:-)

-----Original Message-----
From: Hannes Tschofenig [mailto:[email-masked]] 
Sent: Wednesday, July 19, 2006 7:56 AM
To: [email-masked]
Subject: [Dime] IETF#66 Meeting Minutes

Hi all,

please take a look at the meeting minutes:
http://www3.ietf.org/proceedings/06jul/minutes/dime.txt

Ciao
Hannes

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

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

---

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 05 Aug 2006 14:22:08 +0200

I agree that the meeting minutes are somewhat brief this time.
We will do better with the next IETF meeting...

Ciao
Hannes

---

From: Victor Fajardo <[email-masked]>
Date: Fri, 04 Aug 2006 23:11:10 -0400

Hi Madjid,

I apologize, I will try to recoupe as much info from the last meetings 
as I can.

regards,
victor

---

From: Madjid Nakhjiri <[email-masked]>
Date: Mon, 07 Aug 2006 06:34:55 -0700

No worries, I was being humorous. I wanted to see what was said during the
meeting regarding the Mobile IP6 drafts. I tried to see the archive
discussions, but did not see anything in June or July either.
I am seeing all this discussion on the use of App IDs on the ML, so I wanted
to see if MIP6 is getting its own App ID, or it is using the App ID assigned
to Mobile IP in 3588?

R,

Madjid

-----Original Message-----
From: Hannes Tschofenig [mailto:[email-masked]] 
Sent: Saturday, August 05, 2006 5:22 AM
To: Madjid Nakhjiri
Cc: [email-masked]
Subject: Re: [Dime] IETF#66 Meeting Minutes

Ciao
Hannes

---

From: Julien Bournelle <[email-masked]>
Date: Mon, 7 Aug 2006 15:41:33 +0200

HI madjid,

On Mon, Aug 07, 2006 at 06:34:55AM -0700, Madjid Nakhjiri wrote:
> to Mobiloe IP in 3588?

 basically the question is: do we need a specific App ID or do a
 Service-Type AVP (indicating that it's a HA for the split scenario) is
 sufficient ?

 regards,

 Julien

-- 
julien.bournelle at int-evry.fr

---

From: Madjid Nakhjiri <[email-masked]>
Date: Mon, 07 Aug 2006 07:02:09 -0700

Hi Victor, 

No need to apologize. Minute taking is a volunteer work and sometime minute
takers get busy with Microphone discussion. I did not know who took it. I
follow up with the presenters. 

I remember there was some discussion on MIP6 drafts and use of App ID.
Basically my confusion is about the fact that the base spec 3588 has an App
ID for Mobile IP general, while 4004 is only on MIP4. Are you going to
revise 3588 to have two App IDs? One for MIP4 and one for MIP6? Or is there
another way to distinguish between the two?

Thanks,

Madjid

-----Original Message-----
From: Victor Fajardo [mailto:[email-masked]] 
Sent: Friday, August 04, 2006 8:11 PM
To: Madjid Nakhjiri
Cc: 'Hannes Tschofenig'; [email-masked]
Subject: Re: [Dime] IETF#66 Meeting Minutes

Hi Madjid,

regards,
victor

---

From: "Tschofenig, Hannes" <[email-masked]>
Date: Mon, 7 Aug 2006 16:21:26 +0200

Hi Madjid, 

> to see if MIP6 is getting its own App ID, or it is using the 
This is essentially the main question with the work on the mobility
protocols. From the discussions I couldn't see a rough consensus. Hence,
I will read through the discussions again, summarize them and see what
we can do. I plan to send something to the list this week to move the
work forward. 

Ciao
Hannes

---

From: Madjid Nakhjiri <[email-masked]>
Date: Tue, 08 Aug 2006 16:51:08 -0700

Hi Julien,

I just looked at the RFC 4005 definition of Service_Type.
The services listed there are quite mixed. I am not quite sure what
applications besides NASREQ are supposed to support Service_Type? Or is it
that Mobile IP application assumes NASREQ must be supported?

If one is to go about without modifying RFC 3588 that uses just one App ID
for Mobile IP, then I guess there is just one choice of having

two Service_types for Mobile IPv6 
and 
one Service_Type for Mobile IPv4, 

(3 total for Mobile IP), but then don't you have to modify RFC 4004 to add
the service_type to Mobile IPv4?

Madjid

-----Original Message-----
From: Julien Bournelle [mailto:[email-masked]] 
Sent: Monday, August 07, 2006 6:42 AM
To: Madjid Nakhjiri
Cc: 'Hannes Tschofenig'; [email-masked]
Subject: Re: [Dime] MIP6 App ID/ was: IETF#66 Meeting Minutes

HI madjid,

 regards,

 Julien

---

From: Julien Bournelle <[email-masked]>
Date: Wed, 9 Aug 2006 10:39:27 +0200

Hi madjid,

> that Mobile IP application assumes NASREQ must be supported?

 Let me try to sum up the issue:

 In the split scenario, the HA acts as a IKEv2 responder and uses EAP
 (oIKEv2) to authenticate the user (of the MN). The HA then relies on a
 EAP/AAA server and thus could use Diameter EAP. THe problem that we
 have here is that we are not performing AAA for "basic" network access
 but for the IPv6 Mobility service. Thus we have the problem of, how the
 AAA server knows that. 

 You can take a look at the thread:

 http://www1.ietf.org/mail-archive/web/dime/current/msg00262.html

 for previous discussions on this topic which is still unsolved.

 At this point, as noted in:

 http://www1.ietf.org/internet-drafts/draft-ietf-dime-mip6-split-00.txt

 the 2 options that we have are:

 - define a new Service-Type for "Mobile IPv6 - Split" and puts it in
   DER message (Diameter EAP Request)
 - define a new Application-ID and re-use Diameter EAP messages.

 Hope it helps,

 regards,

 Julien

---

From: Madjid Nakhjiri <[email-masked]>
Date: Fri, 11 Aug 2006 15:49:18 -0700

Hi Julien,

Thanks for pointing me to the archives.
I have one general issue that maybe is related to me not quite understanding
EAP-IKEv2 and that is EAP is run between a peer and an EAP server (in this
case the backend AAA server). EAP-IKEv2 was designed so that a mature
authentication/key management method could be used within EAP framework.
Running EAP-IKEv2 results in authentication of peer to backend AAA, not to
HA and possibly a key between the peer and AAA server. How does this help
the need for IPsec between MN and HA?

Now as far as the discussions on the archives, RFC 4072 only talks about
carrying EAP over Diameter without talking about what EAP is being used for
(your question: mobility versus access service). I think distinguishing
mobility versus access is a AAA signaling issue not an EAP signaling issue.
In RADIUS and MIP4 it is simpler (look at draft-nakhjiri-radius-mip4-02)
because there are attributes related to MIP4 authentication (such as
MIP-MN-AAA-Authenticator, etc) within the Access Request that tells the
server this is about RADIUS. Diameter on the other hand has the notion of
Application ID and should not rely on explicit hint on this. When we got to
the point of trying to translate Diameter messaging to RADIUS, we had to
resort to port types, because Diameter had different messages (depending on
whether HA or FA were involved) while all RADIUS had was Access
Request/Accepts not recognizing between HA and FA.
Here your case is different. Diameter already has an Application ID for
Mobile IP. That is how you distinguish between access and mobility service,
not through service type. Now there are two choices as I said before:

A) revise 3588 to have one App ID for MIPv4 and one for MIPv6 (separate MIP6
split versus integrated through service types). This of course mean revising
4004 to indicate specifically what MIPv4 App ID is.

B) Use the same App ID of 3588 for both MIP4 and MIP6, but then you have to
define 4 service types
1) MIP4 split
2) MIP4 integrated
3) MIP6 split
4) MIP6 integrated.

I prefer A (I can live with B, if you tie a rope to my neck, just kidding).
I think A is cleaner. I think split-integrated versus MIP4-mip6 are two
different degrees of freedom. Just because MIP4 WG did not make the split
integrated distinction, does not mean the business case cannot exist.
Plus that Avi stated that Service type seems to be mandatory.

Madjid

-----Original Message-----
From: Julien Bournelle [mailto:[email-masked]] 
Sent: Wednesday, August 09, 2006 1:39 AM
To: Madjid Nakhjiri
Cc: 'Julien Bournelle'; 'Hannes Tschofenig'; [email-masked]
Subject: Re: [Dime] MIP6 App ID/ revise RFC 3588???

Hi madjid,

 Hope it helps,

 regards,

 Julien

---

From: "Avi Lior" <[email-masked]>
Date: Tue, 15 Aug 2006 10:01:02 -0400

How about the correct (IMO) option and that is assign this new application its own Application ID.  THis afterall is what an Application ID is supposed to do.

-----Original Message-----
From: Madjid Nakhjiri [mailto:[email-masked]]
Sent: Fri 8/11/2006 6:49 PM
To: 'Julien Bournelle'
Cc: [email-masked]
Subject: RE: [Dime] MIP6 App ID/ revise RFC 3588???
 
Hi Julien,

Madjid

-----Original Message-----
From: Julien Bournelle [mailto:[email-masked]] 
Sent: Wednesday, August 09, 2006 1:39 AM
To: Madjid Nakhjiri
Cc: 'Julien Bournelle'; 'Hannes Tschofenig'; [email-masked]
Subject: Re: [Dime] MIP6 App ID/ revise RFC 3588???

Hi madjid,

 Hope it helps,

 regards,

 Julien

---

From: Madjid Nakhjiri <[email-masked]>
Date: Tue, 15 Aug 2006 07:07:38 -0700

Hi Avi,

Not sure what "correct" means:-) I am planning on looking a bit closer at
3588 to see exactly how "application" and "App ID" is used.

As I said I _prefer_ adding a new Application ID for Mobile IPv6, but then
both RFC 3588 and 4004 needs to be revised to reflect that, I think the harm
for that is minimal anyway, given the fairly rare deployment of 4004 (I
think).

Madjid.

  _____  

From: Avi Lior [mailto:[email-masked]] 
Sent: Tuesday, August 15, 2006 7:01 AM
To: Madjid Nakhjiri; Julien Bournelle
Cc: [email-masked]
Subject: RE: [Dime] MIP6 App ID/ revise RFC 3588???

How about the correct (IMO) option and that is assign this new application
its own Application ID.  THis afterall is what an Application ID is supposed
to do.

-----Original Message-----
From: Madjid Nakhjiri [mailto:[email-masked]]
Sent: Fri 8/11/2006 6:49 PM
To: 'Julien Bournelle'
Cc: [email-masked]
Subject: RE: [Dime] MIP6 App ID/ revise RFC 3588???

Hi Julien,

Madjid

-----Original Message-----
From: Julien Bournelle [mailto:[email-masked]]
Sent: Wednesday, August 09, 2006 1:39 AM
To: Madjid Nakhjiri
Cc: 'Julien Bournelle'; 'Hannes Tschofenig'; [email-masked]
Subject: Re: [Dime] MIP6 App ID/ revise RFC 3588???

Hi madjid,

 Hope it helps,

 regards,

 Julien

---

From: "Avi Lior" <[email-masked]>
Date: Tue, 15 Aug 2006 10:24:31 -0400

I don't think RFC3588 needs to be touched when adding an new Application ID. Neither should

Why do you think you need to touch 3588 or 4004?

-----Original Message-----
From: Madjid Nakhjiri [mailto:[email-masked]]
Sent: Tue 8/15/2006 10:07 AM
To: Avi Lior; 'Julien Bournelle'
Cc: [email-masked]; 'Madjid Nakhjiri'
Subject: RE: [Dime] MIP6 App ID/ revise RFC 3588???
 
Hi Avi,

Not sure what "correct" meansJ I am planning on looking a bit closer at 3588 to see exactly how "application" and "App ID" is used.

As I said I _prefer_ adding a new Application ID for Mobile IPv6, but then both RFC 3588 and 4004 needs to be revised to reflect that, I think the harm for that is minimal anyway, given the fairly rare deployment of 4004 (I think).

Madjid.

________________________________

 

-----Original Message-----
From: Madjid Nakhjiri [mailto:[email-masked]]
Sent: Fri 8/11/2006 6:49 PM
To: 'Julien Bournelle'
Cc: [email-masked]
Subject: RE: [Dime] MIP6 App ID/ revise RFC 3588???

Hi Julien,

Madjid

-----Original Message-----
From: Julien Bournelle [mailto:[email-masked]]
Sent: Wednesday, August 09, 2006 1:39 AM
To: Madjid Nakhjiri
Cc: 'Julien Bournelle'; 'Hannes Tschofenig'; [email-masked]
Subject: Re: [Dime] MIP6 App ID/ revise RFC 3588???

Hi madjid,

 Hope it helps,

 regards,

 Julien

---

From: Madjid Nakhjiri <[email-masked]>
Date: Tue, 15 Aug 2006 09:10:16 -0700

Because RFC 3588 defines a single Application ID for Mobile IP and 3588 is
being revised anyway.

If this was a brand new application, it would not matter, but you already
have one App ID for Mobile IP, that could only be used for MIP4, if you now
define a different App ID for Mip6.

  _____  

From: Avi Lior [mailto:[email-masked]] 
Sent: Tuesday, August 15, 2006 7:25 AM
To: Madjid Nakhjiri; Julien Bournelle
Cc: [email-masked]
Subject: RE: [Dime] MIP6 App ID/ revise RFC 3588???

I don't think RFC3588 needs to be touched when adding an new Application ID.
Neither should

-----Original Message-----
From: Madjid Nakhjiri [mailto:[email-masked]]
Sent: Tue 8/15/2006 10:07 AM
To: Avi Lior; 'Julien Bournelle'
Cc: [email-masked]; 'Madjid Nakhjiri'
Subject: RE: [Dime] MIP6 App ID/ revise RFC 3588???

Hi Avi,

Not sure what "correct" meansJ I am planning on looking a bit closer at 3588
to see exactly how "application" and "App ID" is used.

Madjid.

-----Original Message-----
From: Madjid Nakhjiri [mailto:[email-masked]]
Sent: Fri 8/11/2006 6:49 PM
To: 'Julien Bournelle'
Cc: [email-masked]
Subject: RE: [Dime] MIP6 App ID/ revise RFC 3588???

Hi Julien,

Madjid

-----Original Message-----
From: Julien Bournelle [mailto:[email-masked]]
Sent: Wednesday, August 09, 2006 1:39 AM
To: Madjid Nakhjiri
Cc: 'Julien Bournelle'; 'Hannes Tschofenig'; [email-masked]
Subject: Re: [Dime] MIP6 App ID/ revise RFC 3588???

Hi madjid,

 Hope it helps,

 regards,

 Julien

---

From: "Avi Lior" <[email-masked]>
Date: Tue, 15 Aug 2006 12:25:05 -0400

I think that RFC3588 should not define any application ids.  If it does they should be informative.

So if we are going to change 3588 we should remove any reference to any Application IDs.

IANA should be the only authoritative (normative) entity for Application IDS.

-----Original Message-----
From: Madjid Nakhjiri [mailto:[email-masked]]
Sent: Tue 8/15/2006 12:10 PM
To: Avi Lior; 'Julien Bournelle'
Cc: [email-masked]
Subject: RE: [Dime] MIP6 App ID/ revise RFC 3588???
 
Because RFC 3588 defines a single Application ID for Mobile IP and 3588 is being revised anyway.

If this was a brand new application, it would not matter, but you already have one App ID for Mobile IP, that could only be used for MIP4, if you now define a different App ID for Mip6.

 

-----Original Message-----
From: Madjid Nakhjiri [mailto:[email-masked]]
Sent: Tue 8/15/2006 10:07 AM
To: Avi Lior; 'Julien Bournelle'
Cc: [email-masked]; 'Madjid Nakhjiri'
Subject: RE: [Dime] MIP6 App ID/ revise RFC 3588???

Hi Avi,

Madjid.

-----Original Message-----
From: Madjid Nakhjiri [mailto:[email-masked]]
Sent: Fri 8/11/2006 6:49 PM
To: 'Julien Bournelle'
Cc: [email-masked]
Subject: RE: [Dime] MIP6 App ID/ revise RFC 3588???

Hi Julien,

Madjid

-----Original Message-----
From: Julien Bournelle [mailto:[email-masked]]
Sent: Wednesday, August 09, 2006 1:39 AM
To: Madjid Nakhjiri
Cc: 'Julien Bournelle'; 'Hannes Tschofenig'; [email-masked]
Subject: Re: [Dime] MIP6 App ID/ revise RFC 3588???

Hi madjid,

 Hope it helps,

 regards,

 Julien

---

From: <[email-masked]>
Date: Tue, 15 Aug 2006 20:23:50 +0300

Avi,
 
3588 defines the IANA considerations for registering App IDs.  The
document defines the initial Diameter IANA registry. This is standard
procedure.  I don't quite understand what the problem is.
 
John

11.3.  Application Identifiers

   As defined in Section 2.4
<http://tools.ietf.org/html/rfc3588#section-2.4> , the Application
Identifier is used to
   identify a specific Diameter Application.  There are standards-track
   application ids and vendor specific application ids.

   IANA [IANA <http://tools.ietf.org/html/rfc3588#ref-IANA> ] has
assigned the range 0x00000001 to 0x00ffffff for
   standards-track applications; and 0x01000000 - 0xfffffffe for vendor
   specific applications, on a first-come, first-served basis.  The
   following values are allocated.

      Diameter Common Messages            0
      NASREQ                              1 [NASREQ
<http://tools.ietf.org/html/rfc3588#ref-NASREQ> ]
      Mobile-IP                           2 [DIAMMIP
<http://tools.ietf.org/html/rfc3588#ref-DIAMMIP> ]
      Diameter Base Accounting            3
      Relay                               0xffffffff

   Assignment of standards-track application IDs are by Designated
   Expert with Specification Required [IANA
<http://tools.ietf.org/html/rfc3588#ref-IANA> ].

   Both Application-Id and Acct-Application-Id AVPs use the same
   Application Identifier space.

   Vendor-Specific Application Identifiers, are for Private Use.
   Vendor-Specific Application Identifiers are assigned on a First Come,
   First Served basis by IANA.
T

	From: ext Avi Lior [mailto:[email-masked]] 
	Sent: 15 August, 2006 19:25
	To: Madjid Nakhjiri; Julien Bournelle
	Cc: [email-masked]
	Subject: RE: [Dime] MIP6 App ID/ revise RFC 3588???

	I think that RFC3588 should not define any application ids.  If
it does they should be informative.
	
	So if we are going to change 3588 we should remove any reference
to any Application IDs.
	
	IANA should be the only authoritative (normative) entity for
Application IDS.
	
	-----Original Message-----
	From: Madjid Nakhjiri [mailto:[email-masked]]
	Sent: Tue 8/15/2006 12:10 PM
	To: Avi Lior; 'Julien Bournelle'
	Cc: [email-masked]
	Subject: RE: [Dime] MIP6 App ID/ revise RFC 3588???
	
	Because RFC 3588 defines a single Application ID for Mobile IP
and 3588 is being revised anyway.
	
	If this was a brand new application, it would not matter, but
you already have one App ID for Mobile IP, that could only be used for
MIP4, if you now define a different App ID for Mip6.

	

	I don't think RFC3588 needs to be touched when adding an new
Application ID. Neither should

	-----Original Message-----
	From: Madjid Nakhjiri [mailto:[email-masked]]
	Sent: Tue 8/15/2006 10:07 AM
	To: Avi Lior; 'Julien Bournelle'
	Cc: [email-masked]; 'Madjid Nakhjiri'
	Subject: RE: [Dime] MIP6 App ID/ revise RFC 3588???
	
	Hi Avi,

	Not sure what "correct" meansJ I am planning on looking a bit
closer at 3588 to see exactly how "application" and "App ID" is used.
	
	As I said I _prefer_ adding a new Application ID for Mobile
IPv6, but then both RFC 3588 and 4004 needs to be revised to reflect
that, I think the harm for that is minimal anyway, given the fairly rare
deployment of 4004 (I think).

	Madjid.

	

	How about the correct (IMO) option and that is assign this new
application its own Application ID.  THis afterall is what an
Application ID is supposed to do.

	-----Original Message-----
	From: Madjid Nakhjiri [mailto:[email-masked]]
	Sent: Fri 8/11/2006 6:49 PM
	To: 'Julien Bournelle'
	Cc: [email-masked]
	Subject: RE: [Dime] MIP6 App ID/ revise RFC 3588???
	
	Hi Julien,
	
	Thanks for pointing me to the archives.
	I have one general issue that maybe is related to me not quite
understanding
	EAP-IKEv2 and that is EAP is run between a peer and an EAP
server (in this
	case the backend AAA server). EAP-IKEv2 was designed so that a
mature
	authentication/key management method could be used within EAP
framework.
	Running EAP-IKEv2 results in authentication of peer to backend
AAA, not to
	HA and possibly a key between the peer and AAA server. How does
this help
	the need for IPsec between MN and HA?
	
	Now as far as the discussions on the archives, RFC 4072 only
talks about
	carrying EAP over Diameter without talking about what EAP is
being used for
	(your question: mobility versus access service). I think
distinguishing
	mobility versus access is a AAA signaling issue not an EAP
signaling issue.
	In RADIUS and MIP4 it is simpler (look at
draft-nakhjiri-radius-mip4-02)
	because there are attributes related to MIP4 authentication
(such as
	MIP-MN-AAA-Authenticator, etc) within the Access Request that
tells the
	server this is about RADIUS. Diameter on the other hand has the
notion of
	Application ID and should not rely on explicit hint on this.
When we got to
	the point of trying to translate Diameter messaging to RADIUS,
we had to
	resort to port types, because Diameter had different messages
(depending on
	whether HA or FA were involved) while all RADIUS had was Access
	Request/Accepts not recognizing between HA and FA.
	Here your case is different. Diameter already has an Application
ID for
	Mobile IP. That is how you distinguish between access and
mobility service,
	not through service type. Now there are two choices as I said
before:
	
	A) revise 3588 to have one App ID for MIPv4 and one for MIPv6
(separate MIP6
	split versus integrated through service types). This of course
mean revising
	4004 to indicate specifically what MIPv4 App ID is.
	
	B) Use the same App ID of 3588 for both MIP4 and MIP6, but then
you have to
	define 4 service types
	1) MIP4 split
	2) MIP4 integrated
	3) MIP6 split
	4) MIP6 integrated.
	
	I prefer A (I can live with B, if you tie a rope to my neck,
just kidding).
	I think A is cleaner. I think split-integrated versus MIP4-mip6
are two
	different degrees of freedom. Just because MIP4 WG did not make
the split
	integrated distinction, does not mean the business case cannot
exist.
	Plus that Avi stated that Service type seems to be mandatory.
	
	Madjid
	
	-----Original Message-----
	From: Julien Bournelle [mailto:[email-masked]]
	Sent: Wednesday, August 09, 2006 1:39 AM
	To: Madjid Nakhjiri
	Cc: 'Julien Bournelle'; 'Hannes Tschofenig'; [email-masked]
	Subject: Re: [Dime] MIP6 App ID/ revise RFC 3588???
	
	Hi madjid,

	
	 In the split scenario, the HA acts as a IKEv2 responder and
uses EAP
	 (oIKEv2) to authenticate the user (of the MN). The HA then
relies on a
	 EAP/AAA server and thus could use Diameter EAP. THe problem
that we
	 have here is that we are not performing AAA for "basic" network
access
	 but for the IPv6 Mobility service. Thus we have the problem of,
how the
	 AAA server knows that.

	

	
	
	 - define a new Service-Type for "Mobile IPv6 - Split" and puts
it in
	   DER message (Diameter EAP Request)
	 - define a new Application-ID and re-use Diameter EAP messages.
	
	 Hope it helps,
	
	 regards,
	
	 Julien
	
	> > No worries, I was being humorous. I wanted to see what was
said during
	the
	> > I am seeing all this discussion on the use of App IDs on the
ML, so I
	> wanted
	> > to see if MIP6 is getting its own App ID, or it is using the
App ID
	> assigned

---

From: <[email-masked]>
Date: Tue, 15 Aug 2006 20:26:23 +0300

3588 defines MIP(v4). If we think that a common App ID, that's fine. If
we think a seperate MIPv6 App ID is needed, than that is OK. I don't
think that which document these are defined are important (IMO). We can
define a new RFC that extends/updates 4004 for MIPv6, for example, if
needed. 
 
I'm happy just getting consensus on the technical issues here, not on
the documentation, at the moment.
 
John

	From: ext Madjid Nakhjiri [mailto:[email-masked]] 
	Sent: 15 August, 2006 19:10
	To: 'Avi Lior'; 'Julien Bournelle'
	Cc: [email-masked]
	Subject: RE: [Dime] MIP6 App ID/ revise RFC 3588???

	

	 

	
	-----Original Message-----
	From: Madjid Nakhjiri [mailto:[email-masked]]
	Sent: Tue 8/15/2006 10:07 AM
	To: Avi Lior; 'Julien Bournelle'
	Cc: [email-masked]; 'Madjid Nakhjiri'
	Subject: RE: [Dime] MIP6 App ID/ revise RFC 3588???
	
	Hi Avi,

	

	Madjid.

	

	
	-----Original Message-----
	From: Madjid Nakhjiri [mailto:[email-masked]]
	Sent: Fri 8/11/2006 6:49 PM
	To: 'Julien Bournelle'
	Cc: [email-masked]
	Subject: RE: [Dime] MIP6 App ID/ revise RFC 3588???
	
	Hi Julien,

	

	
	Madjid
	
	-----Original Message-----
	From: Julien Bournelle [mailto:[email-masked]]
	Sent: Wednesday, August 09, 2006 1:39 AM
	To: Madjid Nakhjiri
	Cc: 'Julien Bournelle'; 'Hannes Tschofenig'; [email-masked]
	Subject: Re: [Dime] MIP6 App ID/ revise RFC 3588???
	
	Hi madjid,

	

	

	

	 Hope it helps,
	
	 regards,
	
	 Julien
	
said during
	the
ML, so I
App ID

---

From: <[email-masked]>
Date: Tue, 15 Aug 2006 20:27:25 +0300

Agree with Avi.  

	From: ext Avi Lior [mailto:[email-masked]] 
	Sent: 15 August, 2006 17:01
	To: Madjid Nakhjiri; Julien Bournelle
	Cc: [email-masked]
	Subject: RE: [Dime] MIP6 App ID/ revise RFC 3588???

	
	-----Original Message-----
	From: Madjid Nakhjiri [mailto:[email-masked]]
	Sent: Fri 8/11/2006 6:49 PM
	To: 'Julien Bournelle'
	Cc: [email-masked]
	Subject: RE: [Dime] MIP6 App ID/ revise RFC 3588???
	
	Hi Julien,

	

	
	Madjid
	
	-----Original Message-----
	From: Julien Bournelle [mailto:[email-masked]]
	Sent: Wednesday, August 09, 2006 1:39 AM
	To: Madjid Nakhjiri
	Cc: 'Julien Bournelle'; 'Hannes Tschofenig'; [email-masked]
	Subject: Re: [Dime] MIP6 App ID/ revise RFC 3588???
	
	Hi madjid,

	

	

	

	 Hope it helps,
	
	 regards,
	
	 Julien
	
said during
	the
ML, so I
App ID

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 15 Aug 2006 10:36:35 -0700

> the need for IPsec between MN and HA?

two things here

1. the HA relies on the fact that the MN was authenticated
by the AAA server in the home domain.
2. if the EAP method used generates a key (MSK) between the
MN and the HA, the MSK is used to generated the AUTH payload
in the IKEv2 exchange. basically the MSK becomes the shared
key for IKE authentication.

> 4004 to indicate specifically what MIPv4 App ID is.

adding an application ID should not require revising RFC
3588. see the Applications ID section at
http://www.iana.org/assignments/aaa-parameters.

Vijay