idnits 2.17.1 draft-pegrum-vmmt-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-19) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 6 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 7 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 37 has weird spacing: '...t draft is in...' == Line 91 has weird spacing: '...packets to VP...' -- 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 (March 1998) is 9532 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) == Missing Reference: '2' is mentioned on line 232, but not defined Summary: 9 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Pegrum 3 Internet Draft D. Jamieson 4 Expiration Date: September 1998 M. Yuen 5 Nortel (Northern Telecom) Ltd. 6 March 1998 8 VPN Multipoint to Multipoint Tunnel Protocol (VMMT) 9 draft-pegrum-vmmt-00.txt 11 Status of this Memo 12 This document is an Internet-Draft. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, 14 and its working groups. Note that other groups may also distribute 15 working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference 20 material or to cite them other than as ``work in progress'' 22 To learn the current status of any Internet-Draft, please check the 23 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 24 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 25 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 26 ftp.isi.edu (US West Coast) 28 Abstract 30 For many carrier's, the implementation of Virtual Private Network 31 (VPN) services using current IP Tunneling technology is problematic 32 because of onerous configuration requirements. The VMMT is an 33 protocol for the dynammic distribution of VPN information throughout 34 a shared network, and the automatic formation of multi-point to 35 multi-point tunnels between VPN routers. 37 The method described in this internet draft is intended for single 38 AS where the AS administrator is a trusted third party. Traffic 39 seperation is maintained between VPNs. 41 Table of Contents 43 1 Introduction ............................................ 2 44 1.1 Terminology ............................................. 2 45 2 Address Assignment ...................................... 2 46 3 Routing Updates ......................................... 3 47 4 Message Formats ......................................... 4 48 5 VPN Configuration Information Distribution .............. 6 50 RFC NNNN VMMT Protocol March 1998 52 5.1 Multicast Enabled Shared Networks ....................... 53 6 5.2 Non-Multicast Enabled Shared Networks ................... 54 6 6 Summary ................................................. 55 6 7 Security Considerations ................................. 56 7 8 Referneces .............................................. 57 7 9 Author's Address ........................................ 58 7 60 1. Introduction 62 For the purposes of this document, a VPN shall be considered to 63 consist of a grouping of private routers that use a shared tunneled 64 backbone. Multiple VPNs use the shared backbone. 66 Private routers that are members of the same VPN form a peer group. 67 The members of the peer group communicate with each other over a 68 logical shared broadcast medium which is actually the tunnelled 69 backbone simulating a shared broadcast medium for each VPN peer 70 group. 72 In common tunnel implementations, tunnels are point to point 73 connections where the endpoints are statically configured by the 74 network operator. The VMMT protocol dynamically distributes 75 connection information (tunnel endpoints) between VPN peers 76 throughout a shared network, to allow dynamic establishment of a 77 tunnel. The VPN connection information could include multi-cast 78 information allowing the establishment of multi-point to multi-point 79 tunnels. 81 Each VPN peer (router) belonging to a VPN is identified by a 32 bit 82 VPN identifier (VPNID) that is unique in the shared network, but 83 common to all routers belonging to the VPN. 85 2. Address Assignment 87 Each VPN peer would have assigned to it one shared IP address and 88 multiple private IP addresses. The shared IP address is used as the 89 source address in all tunnel IP headers. There is also, optionally, a 90 shared IP multi-cast group address which is used to send VPN 91 multicast or broadcast packets to VPN peers . It also has one 92 private address for each interface into the private network, and one 93 for the interface into the shared network. The private IP address 94 for the interface into the shared network will have the same IP 95 subnet value as all VPN peers. 97 3. Routing Updates 99 RFC NNNN VMMT Protocol March 1998 101 No routing information is exchange between the shared and private 102 networks. Routing updates from the shared network are blocked and 103 not transmitted into the private networks. Conversely, private 104 network updates, even though they are tunnelled across the shared 105 network, are not transmitted into the shared network. 107 RFC NNNN VMMT Protocol March 1998 109 4. Message Formats 111 The message formats follow standard ICMP type messages. The IP 112 Header is not shown in the diagrams below. 114 VPN ICMP Solicitation Message 116 0 1 2 3 117 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 119 | Type | Code | Checksum | 120 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 121 | Num Addrs | Addr Entry Size | 122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 123 | VPN Identifier | 124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 125 | Shared Address | 126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 127 | Private Address | 128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 129 | | 131 IP Header Addresses: 132 Destination Address: Shared Network IP Address 133 Source Address: Shared Network IP Address 135 ICMP Fields: 136 Type: VPN Solicitation Type 137 Code: 0 138 Checksum: 16 bit one's complement of entire message 139 Num VPNs: Number of VPNs contained in this message 140 Addr Entry: Size of message in 32 bit words 142 RFC NNNN VMMT Protocol March 1998 144 VPN ICMP Advertisement Message 146 0 1 2 3 147 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 149 | Type | Code | Checksum | 150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 151 | Num Addrs | Addr Entry Size | 152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 153 | VPN Identifier | 154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 155 | Shared Address | 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 157 | Private Address | 158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 159 + + 161 Shared Network IP Fields: 162 Destination Address: Shared Network IP Address 163 Source Address: Shared Network IP Address 165 ICMP Fields: 166 Type: VPN Solicitation Type 167 Code: 0 168 Checksum: 16 bit one's complement of entire message 169 Num VPNs: Number of VPNs contained in this message 170 Addr Entry: Size of message in 32 bit words 172 RFC NNNN VMMT Protocol March 1998 174 5. VPN Configuration Information Distribution 176 5.1 Multicast Enabled Shared Networks 178 Each VPN peer is required to join the multicast group that is 179 provisioned for its associated VPN. After joining the multicast 180 group, the VPN peer then executes an ICMP Router Discovery [1] like 181 protocol on that multicast group. These messages are a combination of 182 VPN discovery and address resolution. The VPN discovery is meant to 183 be a security measure to ensure that all routers belonging to this 184 multi-cast group belong to the same VPN. This is intended to guard 185 against configuration errors only. It is assumed that the shared 186 network is secure. 188 New VPN peers joining the multi-cast group immediately issue a VPN 189 ICMP Router Solicitation message to trigger advertisements from other 190 routers on the VPN. This provides immediate configuration feedback to 191 the network operator upon switch reconfiguration, by allowing the VPN 192 peer to compare the VPNID advertised with it's own. In addition, each 193 switch periodically issues a VPN Router Advertisement Message to 194 ensure that the VPN integrity is maintained. The default period for 195 Advertisement Messages is every 10 minutes but the network operator 196 can configure the advertisement rate as appropriate for the network. 198 The VPN peers are now able to communicate with one another through 199 standard routing protocols. VPN broadcast messages traverse shared 200 network as a multicast address so that only entities belonging to 201 that VPN see those messages. ARP entries on VPN peers are refreshed 202 when processing the VPN ICMP Advertisement messages received from 203 other peers. The private address resolves into a shared network 204 unicast address. Unicast VPN messages traverse the shared network as 205 unicast tunnelled messages. 207 5.2 Non-Multicast Enabled Shared Networks 209 The VMMT distribution mechanism is the same as in the multi-cast 210 enabled case except that the shared destination address is a 211 broadcast address instead of a multicast group address. 213 6. Summary 215 VMMT addresses several problems: 216 - Dynamic VPN endpoint configuration 217 - Multi-point to Multi-point tunnels. 218 - Security against network operator misconfiguration 219 - Ensures network isolation 221 RFC NNNN VMMT Protocol March 1998 223 The VMMT protocol allows for scalable VPN solutions using a common 224 shared infrastructure. 226 7. Security Considerations 228 This protocol requires the shared network to be secure and trusted. 230 8. References 231 [1] S. Deering, Editor, "ICMP Router Discovery Messages", RFC 1256, 232 Xerox PARC, September 1991 [2] S. Hanks et al., "Generic Router 233 Encapsulation", RFC 1701, NetSmiths Ltd & Cisco Systems, October 234 1994 236 9. Author's Address 238 Scott Pegrum 239 Nortel (Northern Telecom), Ltd. 240 PO Box 3511 Station C 241 Ottawa ON K1Y 4H7 242 Canada 244 EMail: spegrum@Nortel.ca 246 Dwieght Jamieson 247 Nortel (Northern Telecom), Ltd. 248 PO Box 3511 Station C 249 Ottawa ON K1Y 4H7 250 Canada 252 EMail: djamies@Nortel.ca 254 Matthew Yuen 255 Nortel (Northern Telecom), Ltd. 256 PO Box 3511 Station C 257 Ottawa ON K1Y 4H7 258 Canada 260 EMail: myuen@Nortel.ca 262 -------------------------------------------------------------------------- 263 Scott Pegrum 264 Nortel Enterprise Networks 265 Phone: (613) 763-2693 266 Fax: (613) 765-2186 267 email: spegrum@nortel.ca