Network Working Group G. Zorn Internet-Draft Network Zen Intended status: Standards Track Q. Wu Expires: March 18, 2012 Huawei M. Liebsch NEC J. Korhonen NSN September 15, 2011 Diameter Support for Proxy Mobile IPv6 Localized Routing draft-ietf-dime-pmip6-lr-06 Abstract In Proxy Mobile IPv6, packets received from a Mobile Node (MN) by the Mobile Access Gateway (MAG) to which it is attached are typically tunneled to a Local Mobility Anchor (LMA) for routing. The term "localized routing" refers to a method by which packets are routed directly between an MN's MAG and the MAG of its Correspondent Node (CN) without involving any LMA. In order to establish a localized routing session between two Mobile Access Gateways in a Proxy Mobile IPv6 domain, two tasks must be accomplished: 1. The usage of localized routing must be authorized for both MAGs and 2. The address of the MAG to which the Correspondent Node (CN) is attached must be ascertained This document specifies how to accomplish these tasks using the Diameter protocol. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." Zorn, et al. Expires March 18, 2012 [Page 1] Internet-Draft PMIP6 Localized Routing Support September 2011 This Internet-Draft will expire on March 18, 2012. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Zorn, et al. Expires March 18, 2012 [Page 2] Internet-Draft PMIP6 Localized Routing Support September 2011 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 4 3. Attribute Value Pair Definitions . . . . . . . . . . . . . . . 6 3.1. MIP6-Agent-Info AVP . . . . . . . . . . . . . . . . . . . 6 3.2. PMIP6-IPv4-Home-Address AVP . . . . . . . . . . . . . . . 6 3.3. MIP6-Home-Link-Prefix AVP . . . . . . . . . . . . . . . . 6 3.4. MIP6-Feature-Vector AVP . . . . . . . . . . . . . . . . . 6 4. Example Signaling flows . . . . . . . . . . . . . . . . . . . 7 4.1. Localized Routing Service Authorization . . . . . . . . . 7 4.2. Diameter Server Authorizes MAG Location Query . . . . . . 10 5. Localized Routing Service Authorization in Networks with Multiple AAA Servers . . . . . . . . . . . . . . . . . . . . . 13 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 14 9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 14 10. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 14 10.1. draft-ietf-dime-pmip6-lr-03 . . . . . . . . . . . . . . . 14 10.2. draft-ietf-dime-pmip6-lr-04 . . . . . . . . . . . . . . . 15 10.3. draft-ietf-dime-pmip6-lr-05 . . . . . . . . . . . . . . . 15 10.4. draft-ietf-dime-pmip6-lr-06 . . . . . . . . . . . . . . . 16 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 11.1. Normative References . . . . . . . . . . . . . . . . . . . 16 11.2. Informative References . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 Zorn, et al. Expires March 18, 2012 [Page 3] Internet-Draft PMIP6 Localized Routing Support September 2011 1. Introduction Proxy Mobile IPv6 (PMIPv6) [RFC5213] allows the Mobility Access Gateway to optimize media delivery by locally routing packets within itself, avoiding tunneling them to the Mobile Node's Local Mobility Anchor. This is referred to as "local routing" in RFC 5213. However, this mechanism is not applicable to the typical scenarios in which the MN and CN are connected to different MAGs and are registered to the same LMA or different LMAs. In these scenarios (as described in [RFC6279]), the relevant information needed to set up a localized routing path (e.g., the addresses of the Mobile Access Gateways to which the MN and CN are respectively attached) is distributed between their respective Local Mobility Anchors. This may complicate the setup and maintenance of localized routing. Therefore, in order to establish a localized routing path between the two Mobile Access Gateways, the Mobile Node's MAG must identify the LMA that is managing the Correspondent Node's traffic and then obtain the address of the Correspondent Node's MAG from that LMA. In Proxy Mobile IPv6, the LMA to be assigned to the CN may be maintained as a configured entry in the Correspondent Node's policy profile located on an Authentication, Authorization and Accounting (AAA) server. However, there is no relevant work discussing how AAA-based mechanisms can be used by the Mobile Node's LMA to discover the address of the Correspondent Node's LMA during the setup of localized routing. The method by which the Mobile Node's MAG or LMA interacts with the Correspondent Node's LMA to identify the Correspondent Node's MAG is also unspecified. This document describes AAA support for the authorization and discovery of PMIPv6 mobility entities during localized routing. In LMA discovery, Diameter [RFC3588] is used to authorize the localized routing service and provide the Mobile Node's MAG/LMA with information regarding the Correspondent Node's LMA. In MAG discovery, AAA is used to determine whether Mobile Node's MAG is allowed to fetch the address of the Correspondent Node's MAG from the Correspondent Node's LMA. If MAG discovery is successful, the Correspondent Node's LMA will respond to the Mobile Node's MAG with the address of the Correspondent Node's MAG. 2. Solution Overview MAG/LMA discovery is a prerequisite to the establishment of a direct routing path between MAG1 and MAG2 (associated with MN1 and MN2 respectively). This document addresses how to resolve the destination MN's MAG by means of interaction between the LMA and the AAA server. Figure 1 shows the reference architecture for Localized Zorn, et al. Expires March 18, 2012 [Page 4] Internet-Draft PMIP6 Localized Routing Support September 2011 Routing Service Authorization. This reference architecture assumes o MN1 and MN2 belong to different LMAs or the same LMA. If MN1 and MN2 belong to the same LMA, the LMA1 and LMA2 to which MN1 and MN2 are anchored in the figure1 should be the same LMA. If MN1 and MN2 belong to different LMAs, the LMA1 and LMA2 in the figure 1 are in the same provider domain as described in [RFC6279]. o The MAG and LMA support Diameter client functionality. +---------+ LMA2? | AAA & | +------>| Policy |<----------+ | | Profile | | Diameter +---------+ Diameter (Step a) (Step b) | | | | | | LMA2? +--V-+ +----+ | +------->|LMA1| |LMA2|<-------+ | +----+ +----+ | | | | // \\ PMIP // \\ | // \\ | | | | +----+ MAG2? +----+ +---->|MAG1|<-------- |MAG2| +----+ +----+ : : +---+ +---+ |MN1| |MN2| +---+ +---+ Figure 1: Localized Routing Service Authorization Reference Architecture The interaction of the MAG and LMA with the AAA server according to the extension specified in this document considers the follows features: a. The interaction of LMA1 with the AAA server is used to authorize the localized routing service and, if necessary, fetch the IP address of LMA2 (Step a in Figure 1) Zorn, et al. Expires March 18, 2012 [Page 5] Internet-Draft PMIP6 Localized Routing Support September 2011 b. LMA2 interaction with the AAA server is used to determine whether MAG1 or LMA1 is allowed to obtain the IP address of MAG2 (Step b in Figure 1) Note that if MN1 and MN2 are connected to different MAGs but share the same LMA, the interaction between LMA1 and the AAA server should be exactly the same as the case where MNs belong to MAGs under different LMAs. 3. Attribute Value Pair Definitions This section describes Attribute Value Pairs (AVPs) defined by this specification or re-used from existing specifications in a PMIPv6 specific way. 3.1. MIP6-Agent-Info AVP The MIP6-Agent-Info grouped AVP (AVP Code 486) is defined in [RFC5779]. This AVP is used to carry LMA addressing in AAA response. 3.2. PMIP6-IPv4-Home-Address AVP The PMIP6-IPv4-Home-Address AVP (AVP Code 505) is defined in [RFC5779]. This AVP is used to carry the IPv4-MN-HoA [RFC5844] in AAR/Request, from the LMA to the HAAA. 3.3. MIP6-Home-Link-Prefix AVP The MIP6-Home-Link-Prefix AVP (AVP Code 125) is defined in [RFC5779]. This AVP is used to carry the MN-HNP in AAR/request, if available, from the LMA to the HAAA. 3.4. MIP6-Feature-Vector AVP The MIP6-Feature-Vector AVP is originally defined in [RFC5447]. This document defines new capability flag bits according to the IANA rules in RFC 5447. INTER_MAG_ROUTING_SUPPORTED (TBD) Direct routing of IP packets between MNs anchored to the different MAG without involving any LMA is supported. This bit is used with MN-HNP or IPv4-MN-HoA. When a LMA sets this bit in the MIP6- Feature-Vector and MN-HNP or IPv4-MN-HoA corresponding to Correspondent Node is carried with this bit, it indicates to HAAA that Mobile Node associated with this LMA is allowed to use localized routing but the LMA needs to know from HAAA if Zorn, et al. Expires March 18, 2012 [Page 6] Internet-Draft PMIP6 Localized Routing Support September 2011 Correspondent Node is allowed to use localized routing. If the MN-HNPs or IPv4-MN-HoAs corresponding to both Mobile node and Correspondent node are carried with this bit, it indicate that both MN and CN are allowed to use localized routing. Note that localized routing related signaling is required prior localized routing. If this bit is cleared in the returned MIP6-Feature- Vector AVP, the HAAA does not authorize direct routing of packets between MNs anchored to the different MAG. The LMA SHOULD support this policy feature on a per-MN and per-subscription basis. 4. Example Signaling flows 4.1. Localized Routing Service Authorization Localized Routing Service Authorization also can happen during the network access authentication procedure [RFC5779],i.e., before Localized routing is initialized. In this case, the preauthorized pairs of LMA/prefix sets can be downloaded to Proxy Mobile IPv6 entities during RFC5779 procedure. Localized routing can be initiated once a destination of received packet matches to some of the prefixes received during RFC5779 procedure. Figure 2 shows an example scenario where MAG1 acts as a Diameter client, processing the data packet from MN1 to MN2 and requesting authorization of localized routing. In this example scenario, MN1 and MN2 are anchored to LMA1 and LMA2 respectively if MN1 and MN2 belong to the different LMA, otherwise, the LMA to which MN1 and MN2 are anchored should be the same LMA,i.e., LMA1 or LMA2. In the case where MNs belong to the different LMAs, in order to setup a localized routing path with MAG2, MAG1 must first locate the entity that maintains the data required to setup the path (i.e., LMA2) by sending a Request message to LMA1. Note that the discovery of LMA2 is only done once and the request message is Localized routing initialization (LRI) message in the Figure 2 and belong to the Initial phase of the localized routing; once LMA1 has obtained the address of LMA2 from the AAA serer, LMA1 may associate address of LMA2 with the Mobile Node's cached data for future use (e.g., in the case of a handover). The Diameter client in LMA1 sends an AA-Request (AAR) message to the Diameter server. The message contains an instance of the MIP6- Feature-Vector (MFV) AVP ([RFC5447], Section 4.2.5) with the INTER_MAG_ROUTING_SUPPORTED bit (Section 7) set and an instance of the MIP6-Home-Link-Prefix AVP ([RFC5779], Section 5.3) or an instance of the PMIP6-IPv4-Home-Address AVP ([RFC5779], Section 5.2) containing the IP address/HNP of MN2. The Diameter server authorizes localized routing service by checking if MN2 is allowed to use localized routing and if LMA2 and LMA1 are Zorn, et al. Expires March 18, 2012 [Page 7] Internet-Draft PMIP6 Localized Routing Support September 2011 in the same provider domain. if so, the Diameter Server responds with an AA-Answer (AAA) message encapsulating an instance of the MIP6- Agent-Info AVP [RFC5779] containing the IP address and/or Fully Qualified Domain Name (FQDN) of LMA2 and an instance of the MIP6- Feature-Vector (MFV) AVP ([RFC5447], Section 4.2.5) with the INTER_MAG_ROUTING_SUPPORTED bit (Section 7) set indicating Direct routing of IP packets between MNs anchored to the different MAG is supported. . LMA1 then determines the IP address of LMA2 using the data returned in the MIP6-Agent-Info and responds to MAG1 with the address of LMA2 in the localized routing acknowledge message (LRA in the Figure 2). MAG1 can verify whether both MAGs are under the same LMA by comparing LMA1 address with LMA2 address. MAG1 then requests the address of MAG2 from LMA2 and uses that address to setup the localized routing path between itself and MAG2 via a Proxy Binding Update (PBU)/Proxy Binding Acknowledgement (PBA) message exchange [RFC5213]. In the case where MNs share the same LMA, the MAG1 should send a request message (LRI in the Figure 2) to LMA for localized routing which includes IP address of MN2. The subsequent interaction between LMA1 and the AAA should be exact the same as the case where MNs belong to different LMAs. If authorization in the Diameter server is successful, the LMA may look up MAG2 address directly based on IP address of MN2 and respond a message to the MAG1 with IP address of MAG2 included. +---+ +----+ +----+ +---+ +----+ +----+ +---+ |MN1| |MAG1| |LMA1| |AAA| |LMA2| |MAG2| |MN2| +-+-+ +-+--+ +-+--+ +-+-+ +-+--+ +-+--+ +-+-+ | | | | | | | | Anchored | | | Anchored | o------------------o | o-------+--------o Data[MN1->MN2] | | | | | |------->| LRI(MN2)| | | | | | |-------->| | | | | | | |AAR(MFV, MN2) | | | | | |--------->| | | | | | |AAA(MFV, LMA2) | | | | LRA([LMA2]) |<---------| | | | | |<--------| | | | | | | | | | | Figure 2: MAG-initiated Localized Routing Authorization Figure 3 shows another example scenario, in which the LMA1 acts as a Diameter client, processing the data packet from MN2 to MN1 and requesting the authorization of localized routing. In this example Zorn, et al. Expires March 18, 2012 [Page 8] Internet-Draft PMIP6 Localized Routing Support September 2011 scenario, MN1 and MN2 are anchored to LMA1 and LMA2 respectively. In contrast with the signaling flow of Figure 2, the difference is that it is LMA1 instead of MAG1 which initiates the setup of the localized routing path. The Diameter client in LMA1 sends an AA-Request (AAR) message to the Diameter server. The message contains an instance of the MIP6- Feature-Vector AVP ([RFC5447], Section 4.2.5) with the INTER_MAG_ROUTING_SUPPORTED bit set and an instance of the MIP6-Home- Link-Prefix AVP ([RFC5779], Section 5.3) or an instance of the PMIP6- IPv4-Home-Address AVP ([RFC5779], Section 5.2) containing the IP address/HNP of MN2. The Diameter server authorizes localized routing service by checking if MN2 is allowed to use localized routing and if LMA2 and LMA1 are in the same domain. If so, the Diameter server responds with an AA-Answer (AAA) message encapsulating an instance of the MIP6-Agent-Info AVP [RFC5779] containing the IP address and/or Fully Qualified Domain Name (FQDN) of LMA2 and an instance of the MIP6- Feature-Vector (MFV) AVP ([RFC5447], Section 4.2.5) with the INTER_MAG_ROUTING_SUPPORTED bit (Section 7) set indicating Direct routing of IP packets between MNs anchored to the different MAG is supported. . LMA1 then determines the IP address of LMA2 using the data returned in the MIP6-Agent-Info AVP and responds to MAG1 with the address of LMA2. In the case where MNs share the same LMA, the Diameter client in LMA1 sends an AA-Request (AAR) message to the Diameter server. The interaction between LMA1 and the AAA should be exact the same as the case where MNs belong to different LMAs. If authorization in the Diameter server is successful, the LMA may look up MAG2 address directly based on IP address of MN2 and send a request message (LRI in the Figure 3) to the MAG1 for localized routing with IP address of MAG2 included. The MAG1 confirms the success of localized routing if localized routing path can be setup. Zorn, et al. Expires March 18, 2012 [Page 9] Internet-Draft PMIP6 Localized Routing Support September 2011 +---+ +----+ +----+ +---+ +----+ +----+ +---+ |MN1| |MAG1| |LMA1| |AAA| |LMA2| |MAG2| |MN2| +-+-+ +-+--+ +-+--+ +-+-+ +-+--+ +-+--+ +-+-+ | | | | | | | | Anchored | | | Anchored | o--------+-------o Data[MN2->MN1] o-------+--------o | | |<----- | | | | | | |AAR(MFV,MN2) | | | | | |--------->| | | | | LRI |AAA(MFV,LMA2) | | | | (MN2,[LMA2])|<---------| | | | | |<------| | | | | | LRA(Succ) | | | | | | |------>| | | | | Figure 3: LMA-initiated Localized Routing Authorization Figure 4 shows another example scenario, similar to the example scenario illustrated in Figure 3, LMA1 does not respond to MAG1 with the address of LMA2, instead setting up a localized routing path directly between itself and LMA2 via localized routing signaling. +---+ +----+ +----+ +---+ +----+ +----+ +---+ |MN1| |MAG1| |LMA1| |AAA| |LMA2| |MAG2| |MN2| +-+-+ +-+--+ +-+--+ +-+-+ +-+--+ +-+--+ +-+-+ | | | | | | | | Anchored | | | Anchored | o--------+-------o Data[MN2->MN1] o-------+--------o | | |<----- | | | | | | |AAR(MFV,MN2) | | | | | |--------->| | | | | | |AAA(MFV,LMA2) | | | | | |<---------| | | | | | Localized routing setup | | | | |<------------------->| | | Figure 4: LMA-initiated Localized Routing Authorization 4.2. Diameter Server Authorizes MAG Location Query Figure 5 shows an example scenario in which LMA2 acts as a Diameter client, receiving MAG location request and requesting authorization for MAG location Query to the AAA server. In this example scenario, MN1 and MN2 may be anchored to LMA1 and LMA2 respectively or belong to the same LMA. In the case where MNs belong to the different LMAs, MAG1 or LMA1 should has already known the recipient of localized routing is LMA2. If MAG1 initiates LR, MAG1 may take option 1 in the Figure 5 and solicit LMA2 to look up the IP address of the MAG to Zorn, et al. Expires March 18, 2012 [Page 10] Internet-Draft PMIP6 Localized Routing Support September 2011 which MN2 is currently attached (in this case, MAG2) according to the IP addresses/HNPs of MN2. If LMA1 initiate LR, LMA1 may take option 2 in the Figure 5 and solicit LMA2 to look up IP address of the MAG to which MN2 is currently attached. LMA2 validates the request (LRI in the Figure 5) from MAG1 by sending an AAR to the Diameter server containing the IP address/HNP of MN1 (encapsulated in an instance of the MIP6-Home- Link-Prefix AVP or an instance of PMIP6-IPv4-Home- Address AVP) and an instance of the MIP6-Feature- Vector AVP ([RFC5779], Section 5.5) with the INTER_MAG_ROUTING_SUPPORTED bit set. If the authorization is successful, the Diameter server responds with an AA-Answer (AAA) message encapsulating an instance of the MIP6- Feature-Vector (MFV) AVP ([RFC5447], Section 4.2.5) with the INTER_MAG_ROUTING_SUPPORTED bit (Section 7) set indicating Direct routing of IP packets between MNs anchored to the different MAG is supported. LMA2 then looks up the IP address of MAG2 based on the IP address/HNP of MN2 and responds to MAG1 or LMA1 with the IP address of MAG2. Zorn, et al. Expires March 18, 2012 [Page 11] Internet-Draft PMIP6 Localized Routing Support September 2011 +---+ +----+ +----+ +---+ +----+ +----+ +---+ |MN1| |MAG1| |LMA1| |AAA| |LMA2| |MAG2| |MN2| +-+-+ +-+--+ +-+--+ +-+-+ +-+--+ +-+--+ +-+-+ | | | | | | | | Anchored | | | Anchored | o----------------o | o-------+--------o Data[MN1->MN2] | | | | | |------->| | | | | | | | LRI(MN1,MN2 ) | | | | |-------+----------+--------->|\ | | | | | | | | | | | | | AAR(MFV,MN1)|Option 1 | | | | |<-------- | | | | | | | AAA(MFV,LMA1)| | | | | | | |--------->| | | | | | LRA(MAG2 ) | | | | | |<--------------------------- |/ | | | | | | | | | |LRI(MN1,MN2) |\ | | | | +----------+--------->| | | | | | | AAR(MFV,MN1)|Option 2 | | | | |<-------- | | | | | | | AAA(MFV,LMA1)| | | | | | | |--------->| | | | | | | LRA(MAG2) | | | | | | |<------------------- |/ | | | | | | | | | |Localized routing setup | | | |<------+---------------------------->| | | |===================================->| | | | | | | |------->| | | | | | Data[MN2->MN1] |<------ |<-===================================|<-------| | | | | | | | Figure 5: Diameter Server Authorizes MAG Location Query In the case where MNs share the same LMA, LR should be initiated by LMA1(i.e.,LMA2) since only LMA1 knows both MN1 and MN2 belong to itself by lookup its binding cache corresponding to MN1 and MN2. Unlike the case where MNs belong to different LMAs, the interaction between LMAs in option 2 is omitted since LMA1 and LMA2 are the same entity. The interaction between LMA1 and the AAA should be exact the same as the case where MNs belong to different LMAs. Zorn, et al. Expires March 18, 2012 [Page 12] Internet-Draft PMIP6 Localized Routing Support September 2011 5. Localized Routing Service Authorization in Networks with Multiple AAA Servers +------------------------------------+ ( AAA ) ( +--------+ Backend ) ( |Redirect| ) ( | Agent | ) ( +--------+ ) ( ^ ) ( | ) ( | ) ( v ) ( +---------+ +---------+ ) +---->| AAA1 & | | AAA2 & |<---+ | ( | Policy |<-------->| Policy | ) | | ( | Profile | | Profile | ) | | ( +---------+ +---------+ ) | | ( ^ ^ ) | | +----- | ------------------- |-------+ | | A1 A2 | | | | | | | | | Diameter v v Diameter B1 +----+ LMA2 ? +----+ B2 | |LMA1| ------> |LMA2| | | +----+ +----+ | | | | | | // \\ | | // \\ | | // \\ | | | | | | +----+ +----+ | +---->|MAG1| |MAG2|<----+ +----+ +----+ : : +---+ +---+ |MN1| |MN2| +---+ +---+ Figure 6: Use of a Diameter Redirect Agent to Support Localized Routing Service Authorization in Networks with Multiple AAA servers Referring to an architecture with multiple AAA servers (as illustrated in Figure 6), AAA1 may not maintain the LMA to be assigned to MN2 as a configured entry in the Correspondent Node's Policy profile, as AAA2 holds this information in its policy store. In such a case, AAA1 contacts a Diameter redirect agent [RFC3588] to Zorn, et al. Expires March 18, 2012 [Page 13] Internet-Draft PMIP6 Localized Routing Support September 2011 request the AAA server being responsible for maintaining MN2's policy profile. AAA2 checks if MN2 is allowed to use localized routing and if so, responds with the IP address of LMA2 corresponding to MN2 and sends the results back to LMA1 via AAA1. Details about the use of redirect agents in this context are beyond scope of this document. 6. Security Considerations The security considerations for the Diameter NASREQ [RFC4005] and Diameter Proxy Mobile IPv6 [RFC5779] applications are also applicable to this document. The service authorization solicited by the MAG or the LMA relies upon the existing trust relationship between the MAG/LMA and the AAA server. 7. IANA Considerations This specification specifies a new value in the Mobility Capability registry [RFC5447] for use with the MIP6-Feature-Vector AVP: INTER_MAG_ROUTING_SUPPORTED (TBD). 8. Contributors Paulo Loureiro, Jinwei Xia and Yungui Wang all contributed to early versions of this document. 9. Acknowledgement The authors would like to thank Carlos Jesus Bernardos Cano for his valuable comments and suggestions on this document. 10. Change Log 10.1. draft-ietf-dime-pmip6-lr-03 The following are the major changes compared to previous version 02: o Allow return the LMA address in all cases. o Using localized routing for terminology consistency. Zorn, et al. Expires March 18, 2012 [Page 14] Internet-Draft PMIP6 Localized Routing Support September 2011 o Allow localized routing service authorization before localized routing is initialized. o Treat MAGs under the different LMA in the same way as the MAGs under the same LMA. o Get rid of references to individual drafts and only get alignment with Localized routing PS document. 10.2. draft-ietf-dime-pmip6-lr-04 The following are the major changes compared to previous version 03: o Move the last paragraph in section 3 to the first paragraph. o Using "request" rather than "localized routing optimization request". o Using "respond" rather than "localized routing optimization response". o Remove the informative reference to [I-D.wu-netext-local-ro]. o Using "discovery" rather than "resolution". o Section 5 Fix Typo: "LMA"->"LMA2". 10.3. draft-ietf-dime-pmip6-lr-05 The following are the major changes compared to previous version 04: o Redraw the figure 1 to get alignment with the described text. o Section 2 Fix Typo: "the interaction between LMA1 interaction and the AAA server-> the interaction between LMA1 and the AAA server" o Section 3 Fix Typo "the data packet from MN1 to MN2 and requesting -> the data packet from MN2 to MN1 and requesting" o Section 4 Fix Typo: "MAG1 or LMA may solicit-> MAG1 or LMA1 may solicit"" o Differentiate MAG initiated case from LMA initiated case in Figure5 o Add text in section 3 and 4 to explicitly explain how LR authorization works in A21. Zorn, et al. Expires March 18, 2012 [Page 15] Internet-Draft PMIP6 Localized Routing Support September 2011 o Change "localized routing is allowed between MAG1 and MAG2" in section 3,4,5 to "MN2 is allowed to use localized routing". o Update the abstract to make the description consistent o Highlight the figure 2,3,4,5 and related texts are examples of how LR authorization works using Diameter AAA protocol. o Reference Update. 10.4. draft-ietf-dime-pmip6-lr-06 The following are the major changes compared to previous version 05: o Mandate to use MFV in AAA/Answer message. o Add text regarding the use of PMIP6-IPv4-Home-Address [RFC5779]. o Add reference to RFC5844 to support for MN's IPv4-HoA. o Use MIP6-Agent-Info in an AAA/response to carry LMA address. o Use MIP6-Home-Link-Prefix & PMIP6-IPv4-Home-Address in an AAR/ request to carry MN's address. 11. References 11.1. Normative References [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003. [RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, "Diameter Network Access Server Application", RFC 4005, August 2005. [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. [RFC5447] Korhonen, J., Bournelle, J., Tschofenig, H., Perkins, C., and K. Chowdhury, "Diameter Mobile IPv6: Support for Network Access Server to Diameter Server Interaction", RFC 5447, February 2009. [RFC5779] Korhonen, J., Bournelle, J., Chowdhury, K., Muhanna, A., and U. Meyer, "Diameter Proxy Mobile IPv6: Mobile Access Gateway and Local Mobility Anchor Interaction with Zorn, et al. Expires March 18, 2012 [Page 16] Internet-Draft PMIP6 Localized Routing Support September 2011 Diameter Server", RFC 5779, February 2010. [RFC5844] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy Mobile IPv6", RFC 5844, May 2010. 11.2. Informative References [RFC6279] Liebsch, M., Jeong, S., and Q. Wu, "PMIPv6 Localized Routing Problem Statement", RFC 6279, June 2011. Authors' Addresses Glen Zorn Network Zen 227/358 Thanon Sanphawut Bang Na, Bangkok 10260 Thailand Phone: +66 (0) 87-040-4617 Email: gwz@net-zen.net Qin Wu Huawei Technologies Co., Ltd. 101 Software Avenue, Yuhua District Nanjing, Jiangsu 21001 China Phone: +86-25-84565892 Email: sunseawq@huawei.com Marco Liebsch NEC Europe Ltd. Kurfuersten-Anlage 36 Heidelberg, 69115 Germany Email: liebsch@nw.neclab.eu Zorn, et al. Expires March 18, 2012 [Page 17] Internet-Draft PMIP6 Localized Routing Support September 2011 Jouni Korhonen Nokia Siemens Networks Linnoitustie 6 Espoo FI-02600, Finland Email: jouni.nospam@gmail.com Zorn, et al. Expires March 18, 2012 [Page 18]