idnits 2.17.1 draft-maglione-softwire-map-t-scenarios-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 2, 2012) is 4192 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-13) exists of draft-ietf-softwire-map-02 == Outdated reference: A later version (-08) exists of draft-ietf-softwire-map-t-00 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 softwire R. Maglione 3 Internet-Draft Telecom Italia 4 Intended status: Informational W. Dec 5 Expires: May 6, 2013 Cisco 6 November 2, 2012 8 Uses cases for MAP-T 9 draft-maglione-softwire-map-t-scenarios-01 11 Abstract 13 Softwire working group is currently discussing both encapsulation and 14 translation based stateless IPv4/IPv6 solutions in order to be able 15 to provide IPv4 connectivity to customers in an IPv6 only 16 environment. 18 The purpose of this document is to describe some use cases that would 19 take advantage of a translation based solution, by highlighting the 20 operational benefits that a translation based approach would allow. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on May 6, 2013. 39 Copyright Notice 41 Copyright (c) 2012 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Application of Service Policies to the subscriber's 58 sessions . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2.1. Application of Access Control Lists . . . . . . . . . . . . 4 60 2.2. Application of policies based on Deep Packet Inspection . . 5 61 2.3. Application of web-redirection policies . . . . . . . . . . 6 62 2.4. Caching . . . . . . . . . . . . . . . . . . . . . . . . . . 6 63 3. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . 7 64 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 65 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 66 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 67 7. Informative References . . . . . . . . . . . . . . . . . . . . 7 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 70 1. Introduction 72 Softwire working group is currently discussing both encapsulation and 73 translation based stateless IPv4/IPv6 solutions in order to be able 74 to provide IPv4 connectivity to the customers in an IPv6 only 75 environment. There are scenarios where using encapsulation based or 76 translation based approaches does not make substantial differences, 77 however there are many other cases where using a translation approach 78 could lead to significant operational savings for the operators. 80 This document describes some use cases that would take advantage of a 81 translation based solution, by highlighting the operational benefits 82 that a translation based approach would allow. 84 2. Application of Service Policies to the subscriber's sessions 86 In Broadband Networks is common practice for Service Providers to be 87 able to apply per-subscriber policies on customer's traffic at the 88 BNG (Broadband Network Gateway) level. Different services may 89 require the application of different policies. 91 Examples of policies currently used in today's deployments include: 92 o the classification of the traffic not only based on layer 3 93 identifiers, but also based on layer 4 fields, like TCP and/or UDP 94 ports; 95 o the classification of traffic based on destination; 96 o the application of different QoS treatment (could be rate-limit, 97 drop, redirect,.. etc) on selected types of traffic based on layer 98 4-7 classification done by deep packet inspection appliances; 99 o the redirection of selected types of traffic to a Web portal; 100 o the caching of selected types of traffic. 102 The reason why in the current Broadband network, it is important to 103 be able to enforce policies at the BNG is because the BNG is the only 104 network element, interacting with the AAA/RADIUS Server, responsible 105 for authentication, authorization and accounting for the subscriber's 106 sessions. In many common deployments today, the customer's policies 107 are maintained in AAA/RADIUS Server together with the customer's 108 profile and they are applied to the subscriber's session by using 109 standardized RADIUS attributes during the authentication/ 110 authorization phases. 112 In addition in today's deployments, the appliances used to provide 113 value added services, like Deep Packet Inspection devices, caching 114 devices, etc., are usually either co-located or integrated with the 115 BNG box. In order to be able to re-use the current network 116 infrastructure and for operational reasons, it is important for the 117 operators to be able to continue having a single enforcement point, 118 at the BNG level, for all the subscriber's policies for both IPv4 and 119 IPv6 traffic, as opposed to distributing such functionality across 120 two or more nodes. 122 2.1. Application of Access Control Lists 124 Most of the policies described in section Section 2 require the 125 application of an access control list on the BNG in order to be able 126 to classify the user traffic. The application of ACL's on selected 127 subscribers it is usually driven by the AAA/RADIUS through specific 128 RADIUS attributes. 130 This section will explain why the application of some types of ACL's 131 (like for example Destination based ACL and ACL able to match not 132 only layer 3, but also layer 4 fields) can be simply achieved when 133 using MAP-T [I-D.ietf-softwire-map-t]. 135 A key characteristic of MAP-T is the mapping of the IPv4 address of 136 any destination into the IPv6 destination address, by means of the 137 IPv4 to IPv6 mapping rule. Given that in using a regular IPv6 ACL, 138 an operator's main requirement is to be able to identify interesting 139 traffic by means of IPv6 destination addresses, at the BNG level. 140 MAP-T appears the natural approach to solve the problem, without 141 recourse to any non-commonly found device features. In contrast any 142 solution utilizing an IP tunnel based transport (MAP-E 143 [I-D.ietf-softwire-map] or DS-Lite [RFC6333]), effectively hides the 144 payload's IP layer information, making it difficult to identify by 145 means of an IPv6 ACL. 147 Another example of application for MAP-T is where Access Control 148 Lists able to match not only layer 3, but also layer 4 fields, are 149 required. This is a quite common scenario as ACL's matching TCP/UDP 150 ports are widely used in Service Provider's environments in order to 151 classify different traffic types and to apply different qos 152 treatments. In case of an IP tunnel-based transport at the BNG 153 level, the IPv4 traffic is encapsulated inside an IPv6 packet thus 154 the BNG is not able to see the layer 4 fields without either de- 155 encapsulating the packet or by inspecting the IPinIP traffic. On the 156 other hands, using MAP-T, the layer 4 fields would be preserved as 157 the IPv4 traffic is only translated in IPv6 by using the IPv6 MAP 158 rules. With MAP-T the TCP/UDP traffic could be identify at the BNG 159 level by simply using and IPv6 ACL matching the IPv6 prefix and the 160 required TCP/UDP ports. 162 Being able to apply ACL's at the BNG level would allow the operator 163 to not only use regular IPv6 ACL functionality, but also use 164 throughout the same RADIUS interface parameters/system for applying 165 such ACLs. I.e. custom RADIUS interface extensions to deal with the 166 ACL semantics of an IP tunnel based transport are not required. 168 2.2. Application of policies based on Deep Packet Inspection 170 Several Service Providers today use deep packet inspection devices 171 located at the BNG level, in order to inspect the subscriber's 172 traffic for different purposes: profiling the user's behavior, for 173 example in order to be able to provide customized advertisement, 174 classifying the traffic not only based on DSPC/TOS, but also based on 175 layer 4-7 identifiers in order to be able to offer different QoS 176 treatments. 178 Deep packet inspection devices available today in the market and 179 already deployed in operator's network are not able to analyze 180 encapsulated traffic, like IPinIP, and to correlate the inner 181 packet's contents to the outer packet's "subscriber" context - this 182 limitation is consistent across multiple vendors. In order to 183 overcome this limitation when using IP tunnel based transports, 184 without resorting to costly network upgrades, dedicated DPI devices 185 need to be applied at a point in the network where the IP tunnel 186 transport has been stripped and the payload is directly available for 187 native processing. This not only changes the network architecture, 188 but it increases the number of DPI's devices required: one for IPv6 189 traffic at the BNG level, the other for IPv4 traffic on a separate 190 location. In addition the operator would need to enforce policies on 191 two separate places in the network. Furthermore, even with these 192 changes enacted, there remains a critical problem of correlating 193 traffic to a given subscriber: in the DS-Lite and MAP-E solutions, 194 the IPv4 address information in the payload is not sufficient to 195 uniquely identify a subscriber given that an IPv4 address will not be 196 unique. As such, further additional mechanisms and changes to the 197 accounting infrastructure need to be introduced which when combined 198 with all the previous aspects makes this solution operationally 199 complex. 201 With MAP-T operators can continue using the current architectural 202 model with DPI devices installed at the BNG level; the only 203 requirement would be to have the same device able to recognize 204 specific applications on the native IPv6 transport, which DPI devices 205 based on application signatures are capable of doing. In addition 206 with MAP-T the BNG would remain the single enforcement point for all 207 user's policies for all traffic. This would allow the operators to 208 continue using a consistent architecture and set of accounting tools 209 for their network. 211 2.3. Application of web-redirection policies 213 Redirecting the user's traffic to web portal is a common practice in 214 Service Provider's network. It is widely used today for example in 215 order to inform the user about new service offers, or about temporary 216 unavailable services, or in order to allow the user to re-charge is 217 account after his credit has expired, etc ... When web-redirection 218 is activated for a specific subscriber all the http traffic of that 219 customer is the redirected towards an external server. In current 220 deployment web-redirection happens at the BNG level, where the 221 subscriber's traffic first hits the IP network. The activation/ 222 de-activation of redirection policy on selected subscribers may be 223 driven by the AAA/RADIUS through specific RADIUS attributes. 225 If MAP-T is used the redirection of both IPv6 and IPv4 traffic can be 226 kept at the BNG with the same configuration currently used and by 227 simply translating the Server's address in IPv6 with known mapping 228 rules. In case of tunnel based solution the redirection of IPv6 and 229 IPv4 cannot happen in a single place, because the redirection of IPv4 230 traffic must be implemented at or after the v4/v6 gateway responsible 231 for de-encapsulating the traffic. This approach not only would 232 require deploying two separate infrastructures located in different 233 places in order to achieve the redirection for both IPv6 and IPv4 234 traffic, but also it would not allow continuing using the AAA/RADIUS 235 Server infrastructure in order to enforce the redirect policy at the 236 subscriber's session. 238 2.4. Caching 240 With the continuing growing of video traffic, especially considering 241 the increase of http video traffic (you tube like,) it is useful for 242 the Service Providers to be able to cache the video stream at the 243 Edge of the network in order to save bandwidth in upstream links. 244 Using cache devices together with tunnel solutions would introduce 245 similar challenges/issues as the ones described for DPI scenarios, in 246 particular it would require applying caching functionality after the 247 decapsulation point. Obviously this would not eliminate the benefits 248 of the cache. Instead a MAP-T approach would allow caching the 249 subscriber traffic at the edge of the network and gaining the 250 bandwidth savings introduced by the caching. Crucially, any native 251 IPv6 web-caches would be capable of processing IPv6 MAP-T traffic as 252 fully native traffic. 254 In addition in some deployments today, Web Cache Control Protocol 255 (WCCP) feature is used in order to redirect subscriber's traffic to 256 the cache devices. When a subscriber requests a page from a web 257 server (located in the Internet, in this case), the network node 258 where the WCCP is active, sends the request to a Cache Engine. If 259 the cache engine has a copy of the requested page in storage, the 260 engine sends the user that page. Otherwise, the engine gets the 261 requested page and the objects on that page from the web server, 262 stores a copy of the page and its objects (caches them), and forwards 263 the page and objects to the user. WCCP is another example of web 264 redirect thus, the same considerations described in section 265 Section 2.3 and the benefits introduced by MAP-T also apply here. 267 3. Conclusions 269 The use cases described in this document have highlighted a clear 270 need for a MAP-T solution based on Service Providers' operational 271 requirements. 273 This document showed that a MAP-T approach is not a duplication of 274 any other existing IPv4/IPv6 migration mechanisms based on IP 275 tunneling, but actually has capabilities to solve Service Provider's 276 problems. 278 4. Acknowledgements 280 TBD 282 5. IANA Considerations 284 This document does not require any action from IANA. 286 6. Security Considerations 288 TBD 290 7. Informative References 292 [I-D.ietf-softwire-map] 293 Troan, O., Dec, W., Li, X., Bao, C., Matsushima, S., and 294 T. Murakami, "Mapping of Address and Port with 295 Encapsulation (MAP)", draft-ietf-softwire-map-02 (work in 296 progress), September 2012. 298 [I-D.ietf-softwire-map-t] 299 Li, X., Bao, C., Dec, W., Troan, O., Matsushima, S., and 300 T. Murakami, "Mapping of Address and Port using 301 Translation (MAP-T)", draft-ietf-softwire-map-t-00 (work 302 in progress), October 2012. 304 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 305 Stack Lite Broadband Deployments Following IPv4 306 Exhaustion", RFC 6333, August 2011. 308 Authors' Addresses 310 Roberta Maglione 311 Telecom Italia 312 Via Reiss Romoli 274 313 Torino 10148 314 Italy 316 Phone: 317 Email: roberta.maglione@telecomitalia.it 319 Wojciech Dec 320 Cisco 321 Haarlerbergweg 13-19 322 1101 CH Amsterdam, 323 The Netherlands 325 Phone: 326 Fax: 327 Email: wdec@cisco.com 328 URI: