idnits 2.17.1 draft-boucadair-pcp-server-selection-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 (September 13, 2012) is 4236 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 == Outdated reference: A later version (-13) exists of draft-ietf-pcp-dhcp-04 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCP Working Group M. Boucadair 3 Internet-Draft France Telecom 4 Intended status: Standards Track R. Penno 5 Expires: March 17, 2013 D. Wing 6 Cisco 7 September 13, 2012 9 PCP Server Selection 10 draft-boucadair-pcp-server-selection-00 12 Abstract 14 This document specifies the behavior to be followed by the PCP Client 15 to contact its PCP Server(s) when one or several PCP Names are 16 configured. Multiple Names may be configured to a PCP Client in some 17 deployment contexts such as multi-homing. 19 Requirements Language 21 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 22 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 23 document are to be interpreted as described in RFC 2119 [RFC2119]. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on March 17, 2013. 42 Copyright Notice 44 Copyright (c) 2012 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. Name Resolution . . . . . . . . . . . . . . . . . . . . . . . . 3 62 4. IP Address Selection . . . . . . . . . . . . . . . . . . . . . 4 63 4.1. Serial Queries . . . . . . . . . . . . . . . . . . . . . . 4 64 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 5.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 5.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . . . . 5 67 5.3. Example 3 . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 69 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 70 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 71 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 72 9.1. Normative References . . . . . . . . . . . . . . . . . . . 6 73 9.2. Informative References . . . . . . . . . . . . . . . . . . 6 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 76 1. Introduction 78 This document specifies the behavior to be followed by the PCP Client 79 [I-D.ietf-pcp-base] to contact its PCP Server(s) [I-D.ietf-pcp-base] 80 when receiving one or several PCP Names (e.g., DHCP 81 [I-D.ietf-pcp-dhcp]). This document is not specific to DHCP; it is 82 applicable to any mechanism that configures server names. 84 Multiple Names may be configured to a PCP Client in some deployment 85 contexts such as multi-homing. It is out of scope of this document 86 to enumerate all deployment scenarios which require multiple Names to 87 be configured. 89 This document assumes appropriate name resolution means (e.g., 90 Section 6.1.1 of [RFC1123]) are available on the host client. 92 2. Terminology 94 This document makes use of the following terms: 96 o PCP Server denotes a functional element which receives and 97 processes PCP requests from a PCP Client. A PCP Server can be co- 98 located with or be separated from the function (e.g., NAT, 99 Firewall) it controls. Refer to [I-D.ietf-pcp-base]. 100 o PCP Client denotes a PCP software instance responsible for issuing 101 PCP requests to a PCP Server. Refer to [I-D.ietf-pcp-base]. 102 o Name is a domain name that contains one or more labels. In 103 particular, a PCP name may be structured as DNS qualified name or 104 be composed of strings such as can be passed to getaddrinfo 105 (Section 6.1 of [RFC3493]), including address literals, etc. 107 3. Name Resolution 109 Each configured Name is passed to the name resolution library (e.g., 110 Section 6.1.1 of [RFC1123] or [RFC6055]) to retrieve the 111 corresponding IP address(es) (IPv4 or IPv6). Then, the PCP Client 112 MUST follow the procedure specified in Section 4 to contact its PCP 113 Server(s). 115 A host may have multiple network interfaces (e.g, 3G, WiFi, etc.); 116 each configured differently. Each PCP Server learned MUST be 117 associated with the interface via which it was learned. 119 4. IP Address Selection 121 This section specifies the behavior to be followed by the PCP Client 122 to contact its PCP Server(s) when receiving one or several PCP Names: 124 1. If only one PCP Name is configured: if a list of IP addresses is 125 returned as a result of resolving the PCP Server Name, the PCP 126 Client follows the procedure specified in Section 4.1. 127 2. If several PCP Names are configured: each Name is treated as a 128 separate PCP Server. Moreover, each Name may be resolved into 129 one IP address or a list of IP addresses. The PCP Client 130 contacts in parallel the first IP address of each Name and 131 follows the procedure specified in Section 4.1 for the list of IP 132 addresses returned for each Name. Section 5 provides some 133 examples to illustrate this procedure. 135 The discovery procedure may result in a PCP Client instantiating 136 multiple mappings maintained by distinct PCP Servers. The decision 137 to use all these mappings or delete some of them is deployment- 138 specific. Only the client can decide whether all the mappings are 139 needed or only a subset of them. 141 4.1. Serial Queries 143 The PCP Client initializes its retransmission timer, RETRY_TIMER, to 144 2 seconds. The PCP Client sends its PCP message to the PCP Server 145 and waits 2 seconds for a response. If no response is received, it 146 doubles the value of RETRY_TIMER, sends another (identical) PCP 147 message and waits 2*RETRY_TIMER. This procedure is repeated three 148 (3) times, doubling the value of RETRY_TIMER each time. If no 149 response is received after four (4) attempts, the PCP Client tries 150 with the next IP address in its list of PCP Server addresses. If it 151 has exhausted its list, the procedure is repeated every fifteen 152 minutes until the PCP request is successfully answered. If, when 153 sending PCP requests the PCP Client receives an ICMP error (e.g., 154 port unreachable, network unreachable) it SHOULD immediately try the 155 next IP address in the list. Once the PCP Client has successfully 156 received a response from a PCP Server address on that interface, it 157 sends subsequent PCP requests to that same server address until that 158 PCP Server becomes non-responsive, which causes the PCP client to 159 attempt to re-iterate the procedure starting with the first PCP 160 Server address on its list. 162 5. Examples 164 The following sub-sections provide three examples to illustrate the 165 procedure. 167 For all these examples, let's suppose pcpserver-x, pcpserver-y and 168 pcpserver-z are configured as PCP Names. 170 5.1. Example 1 172 Let's also suppose: 174 * IPx1 and IPx2 are returned for pcpserver-x; IPx1 is not reachable. 175 * IPy1 and IPy2 are returned for pcpserver-y; IPy1 is reachable 176 * IPz1 and IPz2 are returned for pcpserver-z; IPz1 is reachable 178 The procedure to contact the PCP Servers is as follows: 180 * Send PCP requests to all servers: IPx1, IPy1 and IPz1 181 * Responses are received from IPy1 and IPz1 but not from IPx1 182 - The request is re-sent to IPx1 183 - If no response is received after four attempts, the request 184 is sent to IPx2 186 5.2. Example 2 188 Now, if the following conditions are made: 190 * IPx1 and IPx2 are returned for pcpserver-x; IPx1 is not reachable. 191 * IPy1 and IPy2 are returned for pcpserver-y; IPy1 is reachable 192 * IPz1 and IPz2 are returned for pcpserver-z; IPz1 is not reachable 194 The procedure to contact the PCP Servers lead to the following: 196 * Send PCP requests to all servers: IPx1, IPy1 and IPz1 197 * A response is received from IPy1 but not from IPx1 and IPz1 198 - the requests are re-sent to IPx1 and IPz1 199 - If no response is received after four attempts, the request 200 is then sent to IPx2 and IPz2 202 5.3. Example 3 204 Let's suppose now that: 206 * IPx1 and IPx2 are returned for pcpserver-x; IPx1 is not reachable. 207 * IPy1 and IPy2 are returned for pcpserver-y; IPy1 is not reachable 208 * IPz1 and IPz2 are returned for pcpserver-z; IPz1 is not reachable 210 The procedure to contact the PCP Servers is as follows: 212 * Send PCP requests to all servers: IPx1, IPy1 and IPz1 213 * No answer is received for all requests 214 - the requests are re-sent to IPx1, IPy1 and IPz1 215 - If no response is received after four attempts, the request 216 is then sent to IPx2, IPy2 and IPz2 218 6. Security Considerations 220 The security considerations in [I-D.ietf-pcp-base] are to be 221 considered. 223 7. IANA Considerations 225 This document does not request any action from IANA. 227 8. Acknowledgements 229 TBC. 231 9. References 233 9.1. Normative References 235 [I-D.ietf-pcp-base] 236 Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. 237 Selkirk, "Port Control Protocol (PCP)", 238 draft-ietf-pcp-base-26 (work in progress), June 2012. 240 [I-D.ietf-pcp-dhcp] 241 Boucadair, M., Penno, R., and D. Wing, "DHCP Options for 242 the Port Control Protocol (PCP)", draft-ietf-pcp-dhcp-04 243 (work in progress), August 2012. 245 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 246 Requirement Levels", BCP 14, RFC 2119, March 1997. 248 9.2. Informative References 250 [RFC1123] Braden, R., "Requirements for Internet Hosts - Application 251 and Support", STD 3, RFC 1123, October 1989. 253 [RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. 254 Stevens, "Basic Socket Interface Extensions for IPv6", 255 RFC 3493, February 2003. 257 [RFC6055] Thaler, D., Klensin, J., and S. Cheshire, "IAB Thoughts on 258 Encodings for Internationalized Domain Names", RFC 6055, 259 February 2011. 261 Authors' Addresses 263 Mohamed Boucadair 264 France Telecom 265 Rennes, 35000 266 France 268 Email: mohamed.boucadair@orange.com 270 Reinaldo Penno 271 Cisco 272 USA 274 Email: repenno@cisco.com 276 Dan Wing 277 Cisco Systems, Inc. 278 170 West Tasman Drive 279 San Jose, California 95134 280 USA 282 Email: dwing@cisco.com