Subject: RE: [Dime] Mobile IPv6 Bootstrapping - "ApplicationID"vs."NAS-Port-Type AVP/Service-Type": Summary

From: "Chowdhury, Kuntal" <[email-masked]>
Date: Mon, 21 Aug 2006 10:26:18 -0400

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Monday, August 21, 2006 8:11 AM
> To: [email-masked]; [email-masked];
> [email-masked]
> Cc: [email-masked]
> Subject: RE: [Dime] Mobile IPv6 Bootstrapping -
"ApplicationID"vs."NAS-
> Port-Type AVP/Service-Type": Summary
> 
> Hi all,
> 
> >> This item is only relevant if you use the Service-Type /
> >NAS-Port Type
> >> approach. The problem raised in the mailing list discussion was
> >> regarding the type of authorization performed by the AAA server. If
> >> the AAA server understands the new values then everything is
> >fine. If
> >> it does not understand them then the authorization decision would
be
> >> treated as a normal network access scenario. Is this desirable?
> >
> >For an operator being able to separate normal access and MIP
> >service is a desirable feature. However, imho that also falls
> >to general operator subscription policies. I.e. whether the
> >operator wants to allow access with and without specific
> >service (such as MIP) or not. In the integrated scenario the
> >MN cannot assume that all access networks support
> >bootstrapping anyway so the AAA server needs to be prepared
> >for both cases.
> 
> Out of curiousity, are there any networks doing this? I assume in
> 3GPP2 networks where MIPv4 is deployed, MIPv4 access isn't an extra,
> billable service.
> 
[KC>] Not that I know of. The parameters for MIP6 bootstrapping are
downloaded to the NAS or to the HA via regular EAP auth (i.e. access
auth at the NAS and IKEv2 auth at the HA) via DER/DEA.
 
> John
> 
> _______________________________________________
> DiME mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/dime

"This email message and any attachments are confidential information of Starent Networks, Corp. The information transmitted may not be used to create or change any contractual obligations of Starent Networks, Corp.  Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this e-mail and its attachments by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify the sender immediately -- by replying to this message or by sending an email to [email-masked] -- and destroy all copies of this message and any attachments without reading or disclosing their contents. Thank you."

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

---

From: "Glen Zorn \(gwz\)" <[email-masked]>
Date: Mon, 21 Aug 2006 13:39:28 -0700

Avi Lior <mailto:[email-masked]> supposedly scribbled:

> Service-Type should not be used.

Agree.

> 
> If you add a new value to the NAS-Port-Type then you need a new
> Application-ID anyway.  You have to make sure that the packet reaches
> an entity that can understands the new value.  Otherewise you could
> end up delivering the packet to a legacy server that doesn't not
> understand the MIPv6 application. 

Right.
  
> 
> Once you have a new Application-ID you really don't need
> NAS-Port-Type (as pointed out correctly by Julien). 

Right.

> 
> I don't understand what the concern about modification of Diameter
> Agents. 

Me, neither.

> 
> If you use Application Id then Relays wont have to change right?
> 
> Proxies would have to change if and only if they are going to be
> proxies for that Application.  But that is the definition of a Proxy
> right? 

Right & right! 
 
...

Hope this helps,

~gwz

Why is it that most of the world's problems can't be solved by simply
  listening to John Coltrane? -- Henry Gabriel