idnits 2.17.1 draft-maglione-softwire-map-t-scenarios-00.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 (October 3, 2012) is 4217 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 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: April 6, 2013 Cisco 6 October 3, 2012 8 Uses cases for MAP-T 9 draft-maglione-softwire-map-t-scenarios-00 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 translations 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 April 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 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 69 1. Introduction 71 Softwire working group is currently discussing both encapsulation and 72 translation based stateless IPv4/IPv6 solutions in order to be able 73 to provide IPv4 connectivity to the customers in an IPv6 only 74 environment. There are scenarios where using encapsulation based or 75 translation based approaches does not make substantial differences, 76 however there are many other cases where using a translation approach 77 could lead to significant operational savings for the operators. 79 This document describes some use cases that would take advantage of a 80 translation based solution, by highlighting the operational benefits 81 that a translations based approach would allow. 83 2. Application of Service Policies to the subscriber's sessions 85 In Broadband Networks is common practice for Service Providers to be 86 able to apply per-subscriber policies on customer's traffic at the 87 BNG (Broadband Network Gateway) level. Different services may 88 require the application of different policies. 90 Examples of policies currently used in today's deployments include: 91 o the classification of the traffic not only based on layer 3 92 identifiers, but also based on layer 4 fields, like TCP and/or UDP 93 ports; 94 o the classification of traffic based on destination; 95 o the application of different QoS treatment (could be rate-limit, 96 drop, redirect,.. etc) on selected types of traffic based on layer 97 4-7 classification done by deep packet inspection appliances; 98 o the redirection of selected types of traffic to a Web portal; 99 o the caching of selected types of traffic. 101 The reason why in the current Broadband network, it is important to 102 be able to enforce policies at the BNG is because the BNG is the only 103 network element, interacting with the AAA/RADIUS Server, responsible 104 for authentication, authorization and accounting for the subscriber's 105 sessions. In many common deployments today, the customer's policies 106 are maintained in AAA/RADIUS Server together with the customer's 107 profile and they are applied to the subscriber's session by using 108 standardized RADIUS attributes during the authentication/ 109 authorization phases. 111 In addition in today's deployments, the appliances used to provide 112 value added services, like Deep Packet Inspection devices, caching 113 devices, etc., are usually either co-located or integrated with the 114 BNG box. In order to be able to re-use the current network 115 infrastructure and for operational reasons, it is important for the 116 operators to be able to continue having a single enforcement point, 117 at the BNG level, for all the subscriber's policies for both IPv4 and 118 IPv6 traffic, as opposed to distributing such functionality across 119 two or more nodes. 121 2.1. Application of Access Control Lists 123 Most of the policies described in section Section 2 require the 124 application of an access control list on the BNG in order to be able 125 to classify the user traffic. The application of ACL's on selected 126 subscribers it is usually driven by the AAA/RADIUS through specific 127 RADIUS attributes. 129 This section will explain why the application of some types of ACL's 130 (like for example Destination based ACL and ACL able to match not 131 only layer 3, but also layer 4 fields) can be simply achieved when 132 using MAP-T. 134 A key characteristic of MAP-T is the mapping of the IPv4 address of 135 any destination into the IPv6 destination address, by means of the 136 IPv4 to IPv6 mapping rule. Given that in using a regular IPv6 ACL, 137 an operator's main requirement is to be able to identify interesting 138 traffic by means of IPv6 destination addresses, at the BNG level. 139 MAP-T appears the natural approach to solve the problem, without 140 recourse to any non-commonly found device features. In contrast any 141 solution utilizing an IP tunnel based transport (MAP-E or DS-Lite), 142 effectively hides the payload's IP layer information, making it 143 difficult to identify by means of an IPv6 ACL. 145 Another example of application for MAP-T is where Access Control 146 Lists able to match not only layer 3, but also layer 4 fields, are 147 required. This is a quite common scenario as ACL's matching TCP/UDP 148 ports are widely used in Service Provider's environments in order to 149 classify different traffic types and to apply different qos 150 treatments. In case of an IP tunnel-based transport at the BNG 151 level, the IPv4 traffic is encapsulated inside an IPv6 packet thus 152 the BNG is not able to see the layer 4 fields without either de- 153 encapsulating the packet or by inspecting the IPinIP traffic. On the 154 other hands, using MAP-T, the layer 4 fields would be preserved as 155 the IPv4 traffic is only translated in IPv6 by using the IPv6 MAP 156 rules. With MAP-T the TCP/UDP traffic could be identify at the BNG 157 level by simply using and IPv6 ACL matching the IPv6 prefix and the 158 required TCP/UDP ports. 160 Being able to apply ACL's at the BNG level would allow the operator 161 to not only use regular IPv6 ACL functionality, but also use 162 throughout the same RADIUS interface parameters/system for applying 163 such ACLs. I.e. custom RADIUS interface extensions to deal with the 164 ACL semantics of an IP tunnel based transport are not required. 166 2.2. Application of policies based on Deep Packet Inspection 168 Several Service Providers today use deep packet inspection devices 169 located at the BNG level, in order to inspect the subscriber's 170 traffic for different purposes: profiling the user's behavior, for 171 example in order to be able to provide customized advertisement, 172 classifying the traffic not only based on DSPC/TOS, but also based on 173 layer 4-7 identifiers in order to be able to offer different QoS 174 treatments. 176 Deep packet inspection devices available today in the market and 177 already deployed in operator's network are not able to analyze 178 encapsulated traffic, like IPinIP, and to correlate the inner 179 packet's contents to the outer packet's "subscriber" context - this 180 limitation is consistent across multiple vendors. In order to 181 overcome this limitation when using IP tunnel based transports, 182 without resorting to costly network upgrades, dedicated DPI devices 183 need to be applied at a point in the network where the IP tunnel 184 transport has been stripped and the payload is directly available for 185 native processing. This not only changes the network architecture, 186 but it increases the number of DPI's devices required: one for IPv6 187 traffic at the BNG level, the other for IPv4 traffic on a separate 188 location. In addition the operator would need to enforce policies on 189 two separate places in the network. Furthermore, even with these 190 changes enacted, there remains a critical problem of correlating 191 traffic to a given subscriber: in the DS-Lite and MAP-E solutions, 192 the IPv4 address information in the payload is not sufficient to 193 uniquely identify a subscriber given that an IPv4 address will not be 194 unique. As such, further additional mechanisms and changes to the 195 accounting infrastructure need to be introduced which when combined 196 with all the previous aspects makes this solution operationally 197 complex. 199 With MAP-T operators can continue using the current architectural 200 model with DPI devices installed at the BNG level; the only 201 requirement would be to have the same device able to recognize 202 specific applications on the native IPv6 transport, which DPI devices 203 based on application signatures are capable of doing. In addition 204 with MAP-T the BNG would remain the single enforcement point for all 205 user's policies for all traffic. This would allow the operators to 206 continue using a consistent architecture and set of accounting tools 207 for their network. 209 2.3. Application of web-redirection policies 211 Redirecting the user's traffic to web portal is a common practice in 212 Service Provider's network. It is widely used today for example in 213 order to inform the user about new service offers, or about temporary 214 unavailable services, or in order to allow the user to re-charge is 215 account after his credit expires, etc ... When web-redirection is 216 activated for a specific subscriber all the http traffic of that 217 customer is the redirected towards an external server. In current 218 deployment web-redirection happens at the BNG level, where the 219 subscriber's traffic first hits the IP network. The activation/ 220 de-activation of redirection policy on selected subscribers may be 221 driven by the AAA/RADIUS through specific RADIUS attributes. 223 If MAP-T is used the redirection of both IPv6 and IPv4 traffic can be 224 kept at the BNG with the same configuration currently used and by 225 simply translating the Server's address in IPv6 with known mapping 226 rules. In case of tunnel based solution the redirection of IPv6 and 227 IPv4 cannot happen in a single place, because the redirection of IPv4 228 traffic must be implemented at or after the v4/v6 gateway responsible 229 for de-encapsulating the traffic. This approach not only would 230 require deploying two separate infrastructures located in different 231 places in order to achieve the redirection for both IPv6 and IPv4 232 traffic, but also it would not allow continuing using the AAA/RADIUS 233 Server infrastructure in order to enforce the redirect policy at the 234 subscriber's session. 236 2.4. Caching 238 With the continuing growing of video traffic, especially considering 239 the increase of http video traffic (you tube like,) it is useful for 240 the Service Providers to be able to cache the video stream at the 241 Edge of the network in order to save bandwidth in upstream links. 242 Using cache devices together with tunnel solutions would introduce 243 similar challenges/issues as the ones described for DPI scenarios, in 244 particular it would require applying caching functionality after the 245 decapsulation point. Obviously this would not eliminate the benefits 246 of the cache. Instead a MAP-T approach would allow caching the 247 subscriber traffic at the edge of the network and gaining the 248 bandwidth savings introduced by the caching. Crucially, any native 249 IPv6 web-caches would be capable of processing IPv6 MAP-T traffic as 250 fully native traffic. 252 In addition in some deployments today, Web Cache Control Protocol 253 (WCCP) feature is used in order to redirect subscriber's traffic to 254 the cache devices. When a subscriber requests a page from a web 255 server (located in the Internet, in this case), the network node 256 where the WCCP is active, sends the request to a Cache Engine. If 257 the cache engine has a copy of the requested page in storage, the 258 engine sends the user that page. Otherwise, the engine gets the 259 requested page and the objects on that page from the web server, 260 stores a copy of the page and its objects (caches them), and forwards 261 the page and objects to the user. WCCP is another example of web 262 redirect thus, the same considerations described in section 263 Section 2.3 and the benefits introduced by MAP-T also apply here. 265 3. Conclusions 267 The use cases described in this document have highlighted a clear 268 need for a MAP-T solution based on Service Providers' operational 269 requirements. 271 This document showed that a MAP-T approach is not a duplication of 272 any other existing IPv4/IPv6 migration mechanisms based on IP 273 tunneling, but actually has capabilities to solve Service Provider's 274 problems. 276 4. Acknowledgements 278 TBD 280 5. IANA Considerations 282 This document does not require any action from IANA. 284 6. Security Considerations 286 TBD 288 Authors' Addresses 290 Roberta Maglione 291 Telecom Italia 292 Via Reiss Romoli 274 293 Torino 10148 294 Italy 296 Phone: 297 Email: roberta.maglione@telecomitalia.it 298 Wojciech Dec 299 Cisco 300 Haarlerbergweg 13-19 301 1101 CH Amsterdam, 302 The Netherlands 304 Phone: 305 Fax: 306 Email: wdec@cisco.com 307 URI: