idnits 2.17.1 draft-reddy-pcp-server-discovery-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 (June 23, 2012) is 4317 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) == Outdated reference: A later version (-29) exists of draft-ietf-pcp-base-26 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCP Working Group T. Reddy 3 Internet-Draft P. Patil 4 Intended status: Standards Track D. Wing 5 Expires: December 25, 2012 F. Baker 6 Cisco 7 June 23, 2012 9 PCP Server Discovery in IPv6 Multihoming 10 draft-reddy-pcp-server-discovery-00 12 Abstract 14 A multihomed network may have a PCP server on each router connecting 15 to each upstream network, providing firewall or prefix translation 16 functions to hosts in the network. In these networks, a PCP client 17 needs to discover all of those PCP servers and then send PCP requests 18 to them individually. 20 This document proposes a multicast mechanism to discover PCP servers. 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 December 25, 2012. 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. Notational Conventions . . . . . . . . . . . . . . . . . . . . 3 58 3. DISCOVER OpCode . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3.1. PCP Server joining a multicast group . . . . . . . . . . . 4 60 3.2. Generating a DISCOVER Request . . . . . . . . . . . . . . . 4 61 3.3. Processing a DISCOVER Request . . . . . . . . . . . . . . . 5 62 3.4. Processing a DISCOVER Response . . . . . . . . . . . . . . 5 63 3.5. Discover Option Packet Format . . . . . . . . . . . . . . . 6 64 4. Operational Considerations . . . . . . . . . . . . . . . . . . 6 65 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 66 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 67 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 68 7.1. Normative References . . . . . . . . . . . . . . . . . . . 7 69 7.2. Informative References . . . . . . . . . . . . . . . . . . 8 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 72 1. Introduction 74 Using Port Control Protocol (PCP) [I-D.ietf-pcp-base] a host can 75 create mappings with its NAT or firewall. PCP expects only one PCP 76 server. In a multihomed network, there may be multiple PCP servers 77 and the PCP client is unaware of all designated PCP Servers in the 78 network. For example, there may be a PCP server integrated into 79 every firewall device connecting to each network. Hence there is a 80 need for PCP client to discover all such PCP Servers with specific 81 functionalities so that the PCP client can make appropriate PCP 82 requests to each one of them. 84 This document proposes a means by which a PCP client can discover all 85 such PCP servers within the network. Each PCP server in the network 86 joins a certain multicast. Using the new DISCOVER OpCode, defined in 87 this document, each PCP client sends a DISCOVER request to that 88 multicast group address. Each PCP server responds with a DISCOVER 89 response. The PCP client then sends regular unicast PCP request 90 messages (e.g., MAP or PEER OpCodes) to each of those discovered PCP 91 servers. 93 2. Notational Conventions 95 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 96 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 97 document are to be interpreted as described in [RFC2119]. 99 3. DISCOVER OpCode 101 DISCOVER : Discover PCP servers listening on specific multicast 102 groups. 104 PCP Servers SHOULD provide a configuration option to allow 105 administrators to disable DISCOVER support if they wish. PCP 106 DISCOVER requests are only designed to discover appropriate PCP 107 servers on the network. The request does not offer functionality 108 defined by other Opcodes described in [I-D.ietf-pcp-base]. 110 The following diagram shows the usage of DISCOVER OpCode, where PCP 111 Server1 and PCP Server2 join the same multicast group (for e.g. ALL- 112 IPv6-FIREWALLS) 113 +------+ +-------------+ +-------------+ 114 | PCP | | PCP Server1 | | PCP Server2 | 115 |Client| | | | | 116 +------+ +-------------+ +-------------+ 117 | | | 118 | PCP DISCOVER Request to ALL-IPv6-FIREWALLS | 119 | | | 120 |--------------------------->|--------------------->| 121 | PCP DISCOVER Response | | 122 |<---------------------------| | 123 | PCP DISCOVER Response | | 124 |<--------------------------------------------------| 125 | | | 126 | | | 127 | PCP MAP/PEER Request | | 128 |--------------------------->| | 129 | PCP MAP/PEER Request | | 130 |-------------------------------------------------->| 131 | | | 132 | PCP MAP/PEER Response | | 133 |<--------------------------------------------------| 134 | PCP MAP/PEER Response | | 135 |<---------------------------| | 136 | | | 138 Figure 1: PCP Server Discover 140 3.1. PCP Server joining a multicast group 142 Each PCP server in the network joins a certain multicast group based 143 on other functionalities embedded with it. Consider a scenario in 144 which a firewall also implements a Port Control Protocol (PCP) 145 [I-D.ietf-pcp-base] Server, in which case it joins a multicast group 146 ALL-IPv6-FIREWALLS. 148 A PCP server can join more than one mutlicast groups if it offers 149 multiple functionalities within the same device. 151 3.2. Generating a DISCOVER Request 153 To discover the PCP servers listening on each of the assigned 154 multicast addresses of interest to the PCP client, the PCP client 155 sends a DISCOVER request to each of those multicast addresses. 157 A Discover Nonce is included in the request by the PCP client. The 158 Discover Nonce is randomly chosen by the PCP client, and is used as 159 part of validation of PCP responses. 161 To accommodate packet loss, the request SHOULD be transmitted several 162 times with a random jitter between them to each of the multicast 163 address. It is RECOMMENDED to transmit the DISCOVER Request a total 164 of three times with the first retransmission after 5 seconds plus a 165 random value between 0-2.5 seconds, and again at 10 seconds plus a 166 random value between 0-5 seconds. 168 Periodic PCP DISCOVER requests should be made to determine the 169 updated list of PCP servers in the network. A PCP client can send 170 DISCOVER messages periodically every 600 seconds to each of the 171 multicast addresses. 173 3.3. Processing a DISCOVER Request 175 When a PCP server listening on one of the multicast groups as 176 described in Section 3.1 receives a PCP DISCOVER Opcode, after 177 successful parsing and processing, it generates a SUCCESS response 178 with zero Assigned Lifetime. If a PCP DISCOVER Request is received 179 on an unassigned multicast group, it should be ignored. 181 Each PCP Server sends a separate DISCOVER response with unicast 182 source address signaling to the PCP client that the source IPv6 183 address of DISCOVER response is the PCP Server address. The Discover 184 Nonce field from the request is copied into the PCP DISCOVER 185 response. 187 3.4. Processing a DISCOVER Response 189 A DISCOVER request sent to the multicast group will result in zero, 190 one, or more responses from each of the addresses multicasted in 191 Section 3.1. If the network contains multiple servers then multiple 192 DISCOVER responses will normally be received. After regular PCP 193 response processing, a PCP client should check using the Discover 194 Nonce from the response to match with a previously sent DISCOVER 195 request and hence also determine the capability of the PCP server. 197 If a DISCOVER request results in one or more DISCOVER response then 198 the client can update its PCP server list with the source addresses 199 of all DISCOVER responses. This list is essentially a list of all 200 PCP Servers in the network. Future specifications that use PCP 201 DISCOVER to discover PCP servers will also define how PCP clients 202 will use the discovered PCP server list. 204 A PCP server may join or leave a network unexpectedly (e.g., device 205 failure, link failure, or link recovery). To accommodate these 206 situations, the PCP client should also periodically send PCP DISCOVER 207 requests to each of the multicast groups to ensure that the client 208 has an updated list of PCP Servers. 210 3.5. Discover Option Packet Format 212 The DISCOVER Opcode has a similar layout for both request and 213 response. 215 The following diagram shows the format of the Opcode-specific 216 information in a request for the DISCOVER Opcode: 218 The Requested Lifetime value MUST be set to zero in the PCP common 219 header. 221 0 1 2 3 222 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 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 | | 225 | Discover Nonce (96 bits) | 226 | | 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 Discover Nonce: Random value chosen by the PCP client. 231 The following diagram shows the format of Opcode-specific information 232 in a response packet for the DISCOVER Opcode: 234 0 1 2 3 235 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 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 | | 238 | Discover Nonce (96 bits) | 239 | | 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 Discover Nonce: Copied from the request. 244 4. Operational Considerations 246 This document defines a set of multicast addresses in several scopes. 247 Operationally, the choice of which scope is appropriate is made by 248 the administration. A reasonable default value in system 249 configurations might be Organization-Local (e.g., all firewalls 250 operated by the organization). However, a large organization might 251 well choose Site-Local or Admin-Local, and consider that "site" or 252 "administrative" domain to include the set of Firewalls advertising a 253 default route into a specific part of its network. 255 5. Security Considerations 257 The principal security threat in this algorithm is a security threat 258 inherent to IP multicast routing and any application that runs on it. 259 A rogue system can join a multicast group and respond to discovery 260 requests pretending to be PCP servers. Discovery of such rogue 261 systems as PCP servers, in itself, is not a security threat if there 262 is a means for the PCP client to authenticate and authorize the 263 discovered PCP servers. 265 In addition, the security considerations in [I-D.ietf-pcp-base] also 266 apply to this use. 268 6. IANA Considerations 270 This note requests of the IANA the assignment of a new PCP Opcode 272 value Opcode 273 ----- --------- 274 TBD DISCOVER 276 This note also requests of the IANA the assignment of a set of 277 multicast addresses as described in Section 2.7 of the IP Version 6 278 Addressing Architecture [RFC4291] from the registry [v6mult]. This 279 set of addresses is referred to as "ALL-IPv6-FIREWALLS". One address 280 should be assigned for each of the following scopes: Link-Local, 281 Admin-Local, Site-Local, and Organization-Local. 283 7. References 285 7.1. Normative References 287 [I-D.ietf-pcp-base] 288 Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. 289 Selkirk, "Port Control Protocol (PCP)", 290 draft-ietf-pcp-base-26 (work in progress), June 2012. 292 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 293 Requirement Levels", BCP 14, RFC 2119, March 1997. 295 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 296 Architecture", RFC 4291, February 2006. 298 7.2. Informative References 300 [v6mult] IANA, "IPv6 Multicast Address Space Registry", 301 December 2011, . 304 Authors' Addresses 306 Tirumaleswar Reddy 307 Cisco Systems, Inc. 308 Cessna Business Park, Varthur Hobli 309 Sarjapur Marathalli Outer Ring Road 310 Bangalore, Karnataka 560103 311 India 313 Email: tireddy@cisco.com 315 Prashanth Patil 316 Cisco Systems, Inc. 317 Cessna Business Park, Varthur Hobli 318 Sarjapur Marthalli Outer Ring Road 319 Bangalore, Karnataka 560103 320 India 322 Email: praspati@cisco.com 324 Dan Wing 325 Cisco Systems, Inc. 326 170 West Tasman Drive 327 San Jose, California 95134 328 USA 330 Email: dwing@cisco.com 332 Fred Baker 333 Cisco Systems, Inc. 334 Santa Barbara, California 93117 335 USA 337 Email: fred@cisco.com