idnits 2.17.1 draft-ietf-softwire-4over6vpns-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 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 253. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 230. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 237. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 243. ** 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (June 9, 2006) is 6524 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) -- Looks like a reference, but probably isn't: '1' on line 81 -- Looks like a reference, but probably isn't: '2' on line 85 -- Looks like a reference, but probably isn't: '3' on line 93 -- Looks like a reference, but probably isn't: '4' on line 176 ** Obsolete normative reference: RFC 2362 (Obsoleted by RFC 4601, RFC 5059) Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Shepherd 3 Internet-Draft Farinacci 4 Expires: December 11, 2006 Cisco Systems 5 Wu 6 Li 7 Cernet 8 June 9, 2006 10 IPv4 unicast/multicast VPNs over an IPv6 core 11 draft-ietf-softwire-4over6vpns-00 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on December 11, 2006. 38 Copyright Notice 40 Copyright (C) The Internet Society (2006). 42 Abstract 44 This document describes a method by which a Service Provider with an 45 IPv6 backbone may provide VPNs (Virtual Private Networks) and MVPNs 46 (Multicast Virtual Private Networks) for its IPv4 customers. The 47 IPv6 core network need only deploy native multicast services using 48 Protocol Independent Multicast (PIM) . All additional functionality 49 described is Customer Edge (CE) based and there are no additional 50 Provider (P) or Provider Edge (PE) protocols. 52 Requirements Language 54 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 55 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 56 document are to be interpreted as described in RFC 2119 [RFC2119]. 58 1. Introduction 60 Current PE based VPN solutions continue to overload functional and 61 scaling requirements onto the PE nodes. The next logical direction 62 for VPN expansion is to move the functionality onto the CE nodes. By 63 doing so, we can remove the need for per-customer routetables inside 64 any provider node. The provider network need only implement a means 65 to control traffic distribution to only those CE nodes participating 66 in a particular VPN instance. 68 This document describes a means by which an IPv6 provider network can 69 use multicast to control traffic distribution between participating 70 VPN CE nodes and how those CE nodes can auto discover all other VPN 71 participating CE nodes without additional protocols nor overloaded 72 extensions to existing protocols. 74 2. Requirements 76 o This is a CE-managed service. That is the service provider PE and 77 P routers only move native IPv6 packets and do not otherwise 78 participate in the customer routing protocols. 80 o The service provider infrastructure runs native multicast services 81 as defined in [1] [RFC2362] so precise multicast replication can be 82 performed among the VPN sites. 84 o A unique IPv6 scoped multicast address is assigned to each VPN 85 customer as defined in [2] [RFC4291]. The multicast group prefix of 86 the VPN could be one of several possibilities: ff05, ff08, or could 87 possibly have a new scope ID assignment. The T flag may also be 1. 89 o Each participating CE of a VPN joins the VPN assigned group 90 creating a multipoint tunnel between the VPN sites so dynamic 91 discovery of the CE devices can occur. Broadcasting over the tunnel 92 is realized by using the IPv6 multicast in the underlying provider 93 network. o ARP protocol as in [3] [RFC0826] is used to discover the 94 underlying tunnel endpoints. The CE nodes ARP over the tunnel for a 95 VPN-based next-hop - on the tunnel's subnet - and the hardware 96 address returned is an IPv6 address internal to the provider network. 98 o Participating CEs within a VPN share a common routing protocol and 99 neighbor adjacencies through the multipoint tunnel. 101 3. Multicast VPNs 103 o PIM runs with the Intergateway Protocol (IGP) at each customer site 104 as well as over the multipoint tunnel through the provider network. 106 o Sending PIM Hello messages are "broadcasted over the multipoint 107 tunnel which ensures only the VPN member CE routers will get the 108 packets. 110 4. Unicast VPNs 112 Each VPN CE member router is configured with the core IPv6 VPN 113 multicast group address, which is effectively a VPN ID. Each CE 114 member router joins this core IPv6 multicast group, creating a 115 multipoint tunnel between each of the CE member routers. The VPN 116 customer IGP runs across this multipoint tunnel, establishing 117 neighbor adjacencies and building a complete customer routing table. 119 By using ARP across the multipoint tunnel to discover the next-hop of 120 each of the CE member neighbors, the learned hardware address 121 returned will be the core-facing IPv6 interface address of the 122 multipoint neighbor. Unicast packets coming from one CE destined to 123 a remote CE VPN neighbor will be unicast encapsulated with the ARP- 124 learned IPv6 next hop of the CE VPN neighbor. 126 5. Packet Fowarding 128 5.1. Unicast 130 Unicast packets are forwarded at the customer site as IPv4 packets to 131 the edge of the network following the IPv4 routed topology. The CE 132 router will encapsulate the IPv4 packets in IPv6 and send to the 133 hardware address learned through the multipoint tunnel across the 134 provider network. The destination CE router will decapsulate and 135 forward the internal IPv4 packet to the unicast destination. 137 5.2. Multicast 139 Multicast can run in any of Any Source Multicast (ASM), Source 140 Specific Multicast (SSM) or BiDirectional (BiDir) within each VPN. 141 For ASM and Bidir the Rendezvous Point (RP) can be located at any of 142 the VPN sites. For joining SSM channels, the member in the receiver 143 site will join a (S,G) which are IPv4 addresses. The IGP routing 144 within the VPN allows the PIM join to travel to the edge and over the 145 multipoint tunnel. The VPN internal multicast state is setup via 146 IPv4 PIM. 148 Multicast forwarding to receivers sites may be a subset of all 149 participating VPN sites and precise replication/forwarding without 150 unwanted traffic to non-receiver CEs may be desired. To facilitate 151 this, the CE router(s) in the receiver sites will take the IPv4 PIM 152 (S,G) join, after sending it over the multipoint tunnel, and the IPv6 153 VPN group address to build an IPv6 PIM (S,G) join where: 155 S is the underlying IPv6 address of the CE router at the source site. 157 G is a group address derived from the VPN IPv6 group address and the 158 IPv4 (S,G) address. 160 The complete group address G will be: 161 ff18:vvvv:ssss:ssss:gggg:gggg::x where s and g are the nibbles of the 162 IPv4 (S,G) address and vvvv is the unique 16-bit VPN ID value. The 163 IPv6 unique VPN multicast address SHOULD comprise only the higher 164 order bits with trailing zeros to allow for at least 64 lower bits to 165 be used for encoding the IPv4 (S,G) address. 167 6. IANA Considerations 169 A new ARP hardward type should be specified to identify the IP 170 address of the interface joined to the multipoint tunnel. 172 7. Security 174 The VPN member CE routers could maintain secure communications 175 through the use of Security Architecture for the Internet Protocol as 176 described in [4] [RFC4301]. 178 8. Normative References 180 [RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or 181 converting network protocol addresses to 48.bit Ethernet 182 address for transmission on Ethernet hardware", STD 37, 183 RFC 826, November 1982. 185 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 186 Requirement Levels", BCP 14, RFC 2119, March 1997. 188 [RFC2362] Estrin, D., Farinacci, D., Helmy, A., Thaler, D., Deering, 189 S., Handley, M., and V. Jacobson, "Protocol Independent 190 Multicast-Sparse Mode (PIM-SM): Protocol Specification", 191 RFC 2362, June 1998. 193 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 194 Architecture", RFC 4291, February 2006. 196 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 197 Internet Protocol", RFC 4301, December 2005. 199 Authors' Addresses 201 Greg Shepherd 202 Cisco Systems 204 Email: shep@cisco.com 206 Dino Farinacci 207 Cisco Systems 209 Email: dino@cisco.com 211 Jianping Wu 212 Cernet 214 Email: jianping@cernet.edu.cn 216 Xing Li 217 Cernet 219 Email: xing@cernet.edu.cn 221 Intellectual Property Statement 223 The IETF takes no position regarding the validity or scope of any 224 Intellectual Property Rights or other rights that might be claimed to 225 pertain to the implementation or use of the technology described in 226 this document or the extent to which any license under such rights 227 might or might not be available; nor does it represent that it has 228 made any independent effort to identify any such rights. Information 229 on the procedures with respect to rights in RFC documents can be 230 found in BCP 78 and BCP 79. 232 Copies of IPR disclosures made to the IETF Secretariat and any 233 assurances of licenses to be made available, or the result of an 234 attempt made to obtain a general license or permission for the use of 235 such proprietary rights by implementers or users of this 236 specification can be obtained from the IETF on-line IPR repository at 237 http://www.ietf.org/ipr. 239 The IETF invites any interested party to bring to its attention any 240 copyrights, patents or patent applications, or other proprietary 241 rights that may cover technology that may be required to implement 242 this standard. Please address the information to the IETF at 243 ietf-ipr@ietf.org. 245 Disclaimer of Validity 247 This document and the information contained herein are provided on an 248 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 249 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 250 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 251 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 252 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 253 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 255 Copyright Statement 257 Copyright (C) The Internet Society (2006). This document is subject 258 to the rights, licenses and restrictions contained in BCP 78, and 259 except as set forth therein, the authors retain all their rights. 261 Acknowledgment 263 Funding for the RFC Editor function is currently provided by the 264 Internet Society.