idnits 2.17.1 draft-toutain-softwire-point6box-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 19. -- Found old boilerplate from RFC 3978, Section 5.5 on line 476. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 453. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 460. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 466. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 68 has weird spacing: '... of the motiv...' == Line 261 has weird spacing: '...mapping must ...' == Line 262 has weird spacing: '...blished betwe...' == Line 263 has weird spacing: '...ntified by us...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 26, 2006) is 6658 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC4057' is defined on line 409, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3633 (Obsoleted by RFC 8415) == Outdated reference: A later version (-05) exists of draft-ietf-dhc-dhcpv6-agentopt-delegate-00 == Outdated reference: A later version (-03) exists of draft-ietf-softwire-problem-statement-00 == Outdated reference: A later version (-02) exists of draft-ietf-dhc-v6-relay-radius-01 -- Obsolete informational reference (is this intentional?): RFC 2461 (Obsoleted by RFC 4861) -- Obsolete informational reference (is this intentional?): RFC 2462 (Obsoleted by RFC 4862) Summary: 7 errors (**), 0 flaws (~~), 10 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group L. Toutain 3 Internet-Draft B. Stevant 4 Expires: July 30, 2006 GET/ENST Bretagne 5 F. Dupont 6 CELAR 7 D. Binet 8 FT R&D 9 January 26, 2006 11 The Point6Box Approach 12 draft-toutain-softwire-point6box-00.txt 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on July 30, 2006. 39 Copyright Notice 41 Copyright (C) The Internet Society (2006). 43 Abstract 45 The Point6Box is an add-on equipment which brings IPv6 connectivity 46 to home and SME in a non-intrusive way. It is a deployment tool 47 which will be replaced by IPv6 native service in term. 49 1. Motivation 51 IPv6 is nowadays implemented in many components such as core network, 52 operating systems and even in several applications, but end-to-end 53 IPv6 connectivity is still missing, especially because very few 54 Internet Access Providers (IAP) offer for IPv6 connectivity and 55 prefixes allocation. The IETF and some companies have defined and/or 56 developed transitions tools like: 6to4, Tunnel Broker or Teredo, but 57 these tools concern either experimented users or do not offer all the 58 IPv6 benefits (always-on, machine to machine communications,...) to 59 build applications. Furthermore, some of these solutions may also 60 lead to some security threat. 62 In this document we present the Point6Box and its counterpart the 63 Point6 Provider Edge (PEv6), two equipments that bring IPv6 64 connectivity to home and SME (Small and Medium Enterprise). This 65 experiment has been launched by the Point6 project in 2005 and fills 66 some of the requirements of the "hub and spoke" problem described by 67 the Softwires working group [ID.problemstatement]. This document 68 gives a short overview of the motivation, architecture and protocols 69 used to solve the problem. 71 The Point6Box is an add-on equipment that can be connected to any 72 CPEv4 or router in order to bring IPv6 connectivity and 73 functionalities in a non-intrusive way. It is important to note that 74 our goal is to fill missing gaps and not to specialize an equipment 75 for IPv6 connectivity. Progressively, when IAP routers and CPE 76 (Customer Premise Equipment) will become IPv6 aware, these 77 functionalities will be included into equipments. 79 Several usages and objectives have been identified in this project: 80 o allow IPv6 connectivity for devices connected in a SME and Home 81 network, in a very easy way, nearly without configuration from the 82 user, 83 o locate IPv6 functionalities on stand-alone and cheap equipment to 84 avoid to rely on desktop computers. Since IPv6 implies to be 85 always-on, the Point6Box has not to be switched off. 86 o allow the introduction of IPv6 demonstrators on existing IPv4 87 network infrastructure. For instance, this allows an R&D division 88 to add features to existing products and to make demonstration to 89 business units. 90 o anticipate new usages. The connectivity offered by the Point6Box 91 is very close to native access. Currently, new applications such 92 as machine to machine communication relying on auto-configuration 93 features and service discovery can be tested. 94 o manage an IPv6 network to discover missing features and debugging 95 existing software to improve quality and reduce exploitation 96 costs. Experiences learned during the transition phase must be 97 directly reused when IPv6 will be run on native infrastructures. 98 o use open source software for CPE and PE and extend functionalities 99 when needed. 100 o use only fully standardized protocols, such as L2TP [RFC2661], 101 PPP, etc. 102 o be able to run over any IPv4 infrastructures (any NAT solutions) 103 to provide a a transition tool to IAPs compliant with future 104 native access architecture. 106 2. Technical description 108 Technically, the Point6Box can be viewed as an IPv6 router with only 109 one Ethernet port plugged into an IPv4 router. Through this port, 110 the Point6Box will establish connectivity to an IPv6 Provider Edge. 111 The tunnel is made over L2TP, which provides three main 112 characteristics: 113 o L2TP messages are carried over UDP to offer NAT-traversal 114 capabilities, 115 o PPP is used to carry IPv6 frames, so we can rely on built-in 116 authentication and configuration mechanisms, and have very easy 117 interaction with AAA servers. 118 o LPC sub-protocol may be used to detect when a tunnel is down, for 119 instance due to an IPv4 address renumbering 121 The Point6Box removes the L2TP encapsulation and forwards incoming 122 IPv6 packets on the link. Generally SME or Home routers interfaces 123 are bridged with an IEEE 802.11 network, so every equipment connected 124 to that network will receive Router Advertisements. IPv6 traffic 125 generated by these equipments will be routed through the Point6Box. 126 IPv4 traffic will continue to be NATed by the IPv4 edge router. 128 The Point6 Provider Edge is connected to the IPv6 backbone. It 129 includes the server part and can be connected to an AAA database to 130 allow authorization and monitoring. The following picture describes 131 the service architecture. 133 /---------------------------\ CPEv6 134 | +--------------+ | DHVPv6 +-----+ 135 | /....>| DHCPv6 relay |<........................>| P | 136 | . +--------------+ | CPEv4 | o | | 137 | . | L2TP IPv6 | | L2TP +-----+ | i | |-- X 138 | . | server |=======================b=== n B | | 139 | v +--------------+ | @@ @@ | r| | t o | | 140 | +--------+ ^ | @ @@ @ | N i|-| 6 x | |-- Y 141 | | DHCPv6 | | |--@ IPv4 @------| A d| +-----+ | 142 | | server | | | @ @@ @ | T g| | 143 | +--------+ | | @@ @@ PEv4 | e|----------| 144 \-------------|-------------/ +-----+ RA-> |-- Z 145 | PEv6 | 146 +--------+ | clients 147 | RADIUS | | RADIUS 148 | server |<-/ 149 +--------+ IPv4/v6 ISP Customer 151 Figure 1: Service Architecture 153 During the initialization part, the Point6Box establishes a PPP 154 peering with the PEv6 through the IPv4 Internet. Parameters required 155 for the configuration of the Point6Box are the IPv4 address of this 156 PE and a login/password. The PEv6 replies with a PPP/CHAP challenge 157 and the Point6Box authenticates itself. The PEv6 queries an AAA 158 server to validate the user authorization. 160 AAA and DNS servers will play an important role in network 161 management. Since only the end system will create addresses, a 162 provider must offer an IPv6 network with prefixes. The AAA server is 163 used to centralize information concerning the user. When the AAA 164 server authenticates the user, it returns a positive acknowledgment 165 and the information concerning the account. We have currently 166 identified three main parameters: 167 o Delegated prefix [ID.delegated]: It is allocated by the provider 168 to the site network. The minimal length can be a commercial 169 agreement between the user and the provider. It may vary between 170 48 and 64 bits regarding the SME/home network topology or the 171 policy the user has with its provider. The prefix allocation is 172 centralized on the AAA server. This allows the provider to get a 173 centralized vision of the mapping between users and allocated 174 prefixes, but the allocation made by the AAA server must have the 175 following properties: stability over time and aggregation in the 176 provider core network. 177 o DNS service: It is used in the traditional way to find the address 178 from name and vice-versa. 180 o DNS domain: In this domain the user can register some equipments 181 through DNS Dynamic Update. The default name could be something 182 like user-login.provider.net. 184 Both ends of the IPv6 tunnel are configured with link-local 185 addresses, and global addresses (for administration purposes). Then, 186 the Point6Box sends a DHCPv6 [RFC3315] request to get the account 187 parameters. The reply contains a prefix (64 bit long (aka. /64) or 188 shorter) [RFC3633] and other parameters previously returned by the 189 AAA server. 191 Auto-configuration of the SME/Home network is a major feature to 192 rapidly spread IPv6. If the SME/Home network includes several 193 routers configuration for IPv4 requires technical skills. We have 194 study several approaches to offer internal routers configuration (see 195 [AINA2005]). In this proposal, we focus on DHCPv6 because it does 196 not require any modification, even if this approach is less efficient 197 in case of multi-homing . 199 The Point6Box includes a DHCPv6 server to answer the requests inside 200 the domain. The static parameters such as DNS resolver and the DNS 201 domain are given to other routers and a pool of /64 prefixes is a 202 constructed based on the prefix received from the provider. An 203 internal router will execute the following algorithm, when one of its 204 interface gets configured through the Neighbor Discovery (ND) 205 [RFC2461] [RFC2462] protocol: 206 o The router sends DHCPv6 requests for a /64 prefix (the interaction 207 with ND as explained in [AINA2005] is used to detect loops or dual 208 prefixes allocation), 209 o The router waits for answers from the Point6Box containing the 210 prefix and other parameters, 211 o The router assigns prefixes to interfaces. It starts unicast and 212 multicast routing and a DHCPv6 relay. The relay functionality is 213 used to allow downstream routers to talk with the DHCPv6 server. 215 At this point, the internal routers are configured, the equipment 216 addresses can be setup through standard Neighbor Discovery protocol 217 and other parameters through DHCPv6. Names and services discovery 218 becomes an important feature in auto-configured networks since 219 addresses cannot be a priori guessed. It is not clear if DNS is the 220 appropriate answer, more experimentation have to be done. In a first 221 approach, we propose to study the Dynamic Update, and offer this 222 service in the provider network. Every host wanting to register to 223 the DNS, has received through DHCPv6 the domain name and the resolver 224 address and can run a script to register its addresses in the direct 225 and reverse DNS. The provider may prevent misleading usage by 226 filtering prefixes. 228 3. PEv6 Architecture overview 230 On the CPEv6 equipment, the interaction between different protocols 231 is relatively simple and in sequence. The L2TP tunnel is open, then 232 a response to the challenge is sent, followed by a ND router 233 solicitation and a DHCPv6 request. The interactions between 234 protocols are more complex on the PEv6 equipment. 236 The PEv6 waits for L2TP connection. The L2TP service is not 237 protected by a shared secret, since this secret will have to be 238 shared between all the customers and will not prevent from a DoS 239 attack. 241 When a CPEv6 opens a tunnel, PPP is activated on that tunnel and a 242 challenge is sent and a response is expected. The response contains 243 the challenge, the answer to the challenge and the customer identity. 244 The PEv6 forwards these values to an AAA (RADIUS [RFC2865] today) 245 server. Currently on our experimentation, the response from the AAA 246 server is just used to accept or not the connection. This should be 247 enhanced in the future and the AAA will return more attributes like 248 delegated prefix and other parameters. 250 Note that the value of the delegated prefix must be as stable as 251 possible, but must depend on the PE location to allow aggregation in 252 the IPv6 core network. So if a customer moves its Point6Box from one 253 place to another, he may not receive the same delegated prefix. 255 The PEv6 receives user-specific IPv6 parameters from the AAA server 256 during access authentication. It cannot send them directly using the 257 PPP/IPv6CP protocol since only Link Local prefixes are negotiated. 258 The PEv6 has to save information returned by the AAA server and to 259 provide them later to the client during DHCPv6 negotiation 261 When the CPEv6 requests DHCPv6 parameters, a mapping must be 262 established between the DUID used by DHCPv6 to identify CPE and 263 information returned by AAA identified by user name. To allow 264 this mapping, a DHCPv6 Relay function is added for each active L2TP 265 tunnel. This relay adds RRAO (Relay agent RADIUS Attribute Option 266 [ID.rrao]) information containing user name to the request anf 267 forwards it to the DHCPv6 server. 269 Since the Point6Box service should maintain for a prefix a mid-term 270 stability, prefix assignments to users are saved in a lease database. 271 The DHCPv6 server may also use attributes provided by RRAO to decide 272 which prefix pool is to be used for this particular user based on 273 information from AAA. 275 The PEv6 needs to know what prefixes are allocated, for instance for 276 route injection. Today the information is snooped by the DHCPv6 277 relay because the right mechanism [ID.notagent] was published after 278 the code was developed. 280 4. Transition 282 As stated before, the goal of the Point6Box is not to install IPv6 283 services on a new equipment. The goal of the Point6Box is to 284 disappear when full connectivity will be established. During that 285 time, the Point6Box will have helped to debug existing 286 implementations, to explore new ways of managing IPv6 networks and to 287 develop missing applications. One possible transition scenario is 288 the integration of Point6Box software into existing CPE, and continue 289 to tunnel IPv6 until all the provider network has been updated to 290 manage natively IPv6. At this time, complete transition will mean 291 merging of IPv4 and IPv6 AAA databases. 293 5. Scenarios and future plans 295 Several scenarios have been identified for a current use of the 296 Point6Box: 297 o offer an easy IPv6 connectivity. The non-intrusive introduction 298 of IPv6 in existing network, will help to demonstrate the benefits 299 of IPv6 (global addresses, auto-configuration, always on,...) 300 without modifying existing architecture. In France, lots of 301 providers are offering triple play services. IPv6 access is 302 incompatible with this offer due to implementation limitation. 303 Using an IPv6 CPE instead of the provider box currently implies 304 loosing television or telephony offers. Point6Box approach allows 305 users to continue to access to all their services and to get an 306 IPv6 connectivity. In that way, the user and the provider may 307 test new services. 308 o deploy the IPv6 in a private network. A company specialized in 309 digital signages has to install display devices in hotels, shops 310 and supermarkets. The use of IPv4 is complex since display 311 equipments are behind a NAT. The media server, which contains the 312 contents update, cannot contact directly the equipments. With 313 IPv6 each equipment has a global and stable address. The media 314 server can send in real time the contents updates. The Point6Box 315 approach will simplify the deployment of such services: 316 1. an authenticated tunnel will be set to the media server 317 2. IPv6 auto-configuration routers and hosts properties will 318 allow equipments to be simply plugged on the network without 319 special configuration. 320 This scenario does not require a full Internet connectivity, since 321 it focuses on a closed group of users. Security features are not 322 blocking, since the Point6Box can strongly authenticate itself to 323 the PEv6. 325 o Experiment new usages: IPv6 network will not be managed in the 326 same way as an IPv4 networks: providers will allocate prefixes 327 instead of addresses, equipments like television set will have an 328 IPv6 address, ... This will lead to other paradigms on 329 networking. The Point6Box may help to find innovative usages, 330 adapt or develop new protocols and services. We currently 331 investigate in network auto-configuration, service discovery, 332 securing auto-configuration and automatic filtering of IPv6 333 Point6Box is a good experimental platform to implement research 334 results. 336 We are also working in mobility features especially in header 337 compression to limit the impact of tunneling overhead on low 338 bandwidth links as wireless networks. This could help to demonstrate 339 new services even when the wireless infrastructure is IPv4 only. 341 6. Acknowledgments 343 The Point6Box development has been made on by a Point6 team (founded 344 by the Brittany Region Council, GET/ENST Bretagne and IRISA/INRIA). 345 This work will not have been possible without the support of Etienne 346 Gallet de Santerre, Herve Le Goff, Yannick Skrzypacz. We would also 347 like to thank the Point6Boxes used by some of the authors to edit 348 this document with IPv6. 350 7. Security Considerations 352 The Point6Box approach uses only already existing protocols so should 353 not introduce new security issues. 355 8. References 357 8.1 Normative References 359 [RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, 360 G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"", 361 RFC 2661, August 1999. 363 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 364 "Remote Authentication Dial In User Service (RADIUS)", 365 RFC 2865, June 2000. 367 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 368 C., and M. Carney, "Dynamic Host Configuration Protocol 369 for IPv6 (DHCPv6)", RFC 3315, July 2003. 371 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 372 Host Configuration Protocol (DHCP) version 6", RFC 3633, 373 December 2003. 375 8.2 Informative References 377 [AINA2005] 378 Chelius, G., Fleury, E., and L. Toutain, "No 379 Administration Protocol (NAP) for IPv6 Router Auto- 380 Configuration", AINA 2005 IEEE 19th International 381 Conference on Advanced Information Networking and 382 Applications, March 2005. 384 [ID.delegated] 385 "RADIUS Delegated-IPv6-Prefix Attribute". 387 [ID.notagent] 388 Droms, R., Volz, B., and O. Troan, "DHCP Relay Agent 389 Assignment Notification Option", 390 draft-ietf-dhc-dhcpv6-agentopt-delegate-00.txt (work in 391 progress), July 2006. 393 [ID.problemstatement] 394 Li, X., Durand, A., Miyakawa, S., Palet, J., Parent, F., 395 and D. Ward, "Softwire Problem Statement", 396 draft-ietf-softwire-problem-statement-00.txt (work in 397 progress), December 2005. 399 [ID.rrao] Wing Cheong Lau, "DHCPv6 Relay agent RADIUS Attribute 400 Option", draft-ietf-dhc-v6-relay-radius-01.txt (work in 401 progress), August 2005. 403 [RFC2461] "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, 404 December 1998. 406 [RFC2462] "IPv6 Stateless Address Autoconfiguration", RFC 2462, 407 December 1998. 409 [RFC4057] Bound, J., "IPv6 Enterprise Network Scenarios", RFC 4057, 410 June 2005. 412 Authors' Addresses 414 Laurent Toutain 415 GET/ENST Bretagne 416 2 rue de la Chataigneraie 417 CS 17607 418 35576 Cesson-Sevigne Cedex 419 France 421 Fax: +33 2 99 12 70 30 422 Email: Laurent.Toutain@enst-bretagne.fr 424 Bruno Stevant 425 GET/ENST Bretagne 426 2 rue de la Chataigneraie 427 CS 17607 428 35576 Cesson-Sevigne Cedex 429 France 431 Fax: +33 2 99 12 70 30 432 Email: Bruno.Stevant@enst-bretagne.fr 434 Francis Dupont 435 CELAR 437 Email: Francis.Dupont@point6.net 439 David Binet 440 FT R&D 442 Email: David.Binet@francetelecom.com 444 Intellectual Property Statement 446 The IETF takes no position regarding the validity or scope of any 447 Intellectual Property Rights or other rights that might be claimed to 448 pertain to the implementation or use of the technology described in 449 this document or the extent to which any license under such rights 450 might or might not be available; nor does it represent that it has 451 made any independent effort to identify any such rights. Information 452 on the procedures with respect to rights in RFC documents can be 453 found in BCP 78 and BCP 79. 455 Copies of IPR disclosures made to the IETF Secretariat and any 456 assurances of licenses to be made available, or the result of an 457 attempt made to obtain a general license or permission for the use of 458 such proprietary rights by implementers or users of this 459 specification can be obtained from the IETF on-line IPR repository at 460 http://www.ietf.org/ipr. 462 The IETF invites any interested party to bring to its attention any 463 copyrights, patents or patent applications, or other proprietary 464 rights that may cover technology that may be required to implement 465 this standard. Please address the information to the IETF at 466 ietf-ipr@ietf.org. 468 Disclaimer of Validity 470 This document and the information contained herein are provided on an 471 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 472 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 473 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 474 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 475 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 476 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 478 Copyright Statement 480 Copyright (C) The Internet Society (2006). This document is subject 481 to the rights, licenses and restrictions contained in BCP 78, and 482 except as set forth therein, the authors retain all their rights. 484 Acknowledgment 486 Funding for the RFC Editor function is currently provided by the 487 Internet Society.