idnits 2.17.1 draft-ypal-sfc-dhcp-option-for-nsh-for-sfp-02.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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 2 longer pages, the longest (page 11) being 67 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 11 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 17 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** There are 14 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (August 16, 2016) is 2782 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 98 == Unused Reference: 'RFC0768' is defined on line 503, but no explicit reference was found in the text == Unused Reference: 'RFC2131' is defined on line 509, but no explicit reference was found in the text == Unused Reference: 'RFC2939' is defined on line 515, but no explicit reference was found in the text == Unused Reference: 'RFC6225' is defined on line 526, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-sfc-nsh' is defined on line 531, but no explicit reference was found in the text == Unused Reference: 'RFC6335' is defined on line 537, but no explicit reference was found in the text == Unused Reference: 'RFC7348' is defined on line 543, but no explicit reference was found in the text == Unused Reference: 'RFC7610' is defined on line 549, but no explicit reference was found in the text == Unused Reference: 'RFC7665' is defined on line 553, but no explicit reference was found in the text == Unused Reference: 'I-D.draft-ietf-sfc-control-plane-06' is defined on line 567, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) == Outdated reference: A later version (-28) exists of draft-ietf-sfc-nsh-00 -- Duplicate reference: RFC2132, mentioned in 'DHCP-OPTIONS', was also mentioned in 'RFC2132'. -- Duplicate reference: RFC2939, mentioned in 'DHCP-IANA', was also mentioned in 'RFC2939'. == Outdated reference: A later version (-08) exists of draft-ietf-sfc-control-plane-06 Summary: 3 errors (**), 0 flaws (~~), 16 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Service Function Chaining (sfc) Yogendra Pal 2 Internet-Draft Cisco 3 Intended status: Experimental Venkata SRG 4 Expires: February 16, 2017 Citrix 5 Vikram Menon 6 Ericsson 7 August 16, 2016 9 DHCP option for NSH in Service Function Path (SFP) 10 draft-ypal-sfc-dhcp-option-for-nsh-for-sfp-02 12 Abstract 14 This draft specifies Dynamic Host Configuration Protocol option 15 (both DHCPv4 and DHCPv6) for NSH aware clients participating in 16 the service function path(SFP) of the service chaining. As part 17 of this proposal SFF and SF will receive the SFP information 18 containing Service Path Identifier(SPI), Transport protocol and 19 Nexthop(NH) address of subsequent SFF/SF. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current 29 Internet-Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on February 16, 2017. 38 Copyright Notice 40 Copyright (c) 2016 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Requirements Language .......................................... 2 56 2. Introduction ................................................... 2 57 2.1 Terminology ................................................ 3 58 3. Model and Applicability ........................................ 3 59 3.1 Example service chain network .............................. 4 60 4. SFP DHCP Option Formats ........................................ 4 61 4.1 DHCPv4 Options ............................................. 7 62 4.2 DHCPv6 Options ............................................. 8 63 5. Request and Processing DHCP SFP Option ......................... 8 64 5.1 DHCPv4 Client Behaviour .................................... 8 65 5.2 DHCPv6 Client Behaviour .................................... 9 66 5.3 DHCP Server Behaviour ...................................... 9 67 6. Security Considerations ........................................ 10 68 7. IANA Considerations ............................................ 10 69 8. Acknowledgements ............................................... 11 70 9. References ..................................................... 11 71 9.1. Normative References ...................................... 11 72 9.2. Informative References .................................... 11 74 1. Requirements Language 76 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 77 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this 78 document are to be interpreted as described in RFC 2119 [RFC2119]. 80 2. Introduction 82 In NSH aware service chaining model, SFF needs to be provisioned with 83 SFP information. In the current environment, the operator 84 manually provisions each network elements(SFF) with SFP information. 85 This does not scale well when on-demand service functions are introduced 86 and brought down in virtualized networks in cloud, datacenter, and so 87 forth deployments. This draft is trying to automate this network rollout 88 of service chaining using the DHCP option. Each SFF willing to 89 participate in NSH aware service chain model will indicate its interest 90 to the DHCP server for SFP and gets provisioned accordingly from the 91 DHCP server. 93 2.1 Terminology 95 This document uses the terminology defined in draft-ietf-sfc-nsh with 96 respect to service function chain. 98 DHCP client: A DHCP [1] client is an Internet host that uses DHCP to 99 obtain configuration parameters such as a network address. 101 DHCP server: A DHCP server is an Internet host that returns 102 configuration parameters to DHCP clients. 104 Service Function Forwarder (SFF): A service function forwarder is 105 responsible for delivering traffic received from the SFCNF to one 106 or more connected service functions, and from service functions to 107 the SFC network forwarder(SFCNF). 109 Service Function (SF): A function that is responsible for specific 110 treatment of received packets. A service function can act at the 111 network layer or other OSI layers. A service function can be a 112 virtual instance or be embedded in a physical network element. 113 One of multiple service functions can be embedded in the same 114 network element. Multiple instances of the service function can 115 be enabled in the same administrative domain. 117 Service Function Path (SFP): The instantiation of a SFC in the 118 network. Packets follow a service function path from a classifier 119 through the requisite service functions. 121 3. Model and Applicability 123 In service chaining model, SFC controller will provision SFF with 124 details of service function paths SFP(s). In order to provision SFP 125 details to SFF(s), controller needs some mechanism to configure the 126 SFF. DHCP protocol is one of the existing mechanism for provisioning 127 various network information to any DHCP clients. 129 Existing DHCP version 4 and 6 will be extended to incorporate option 130 of provisioning dynamically SFP details to SFF. In this case, 131 controller can be considered to act as DHCP server. 133 3.1 Example service chain network 135 See Figure 1, depicting SFF (DHCP clients) interacting with SFC 136 controller (DHCP server) to register and getting provisioned 137 with SFP details. 139 +-------------------------------------------------+ 140 | SFC Control Plane | 141 | (DHCP Server) | 142 +-------------------------------------------------+ 143 ^ ^ 144 | | 145 +-------------------------------------------------+ 146 | DHCP protocol exchanges | 147 | provisioning Service function Path (SFP) | 148 | (SFP1 + SFP2) to SFF Clients | 149 +-------------------------------------------------+ 150 | | 151 | | 152 v v 153 +--------+ +---------+ 154 | SFF | ---(SFP1)---> | SFF | 155 |(DHCPv4 | <---(SFP2)--- | (DHCPv6 | 156 | client)| ........................... | client)| 157 +--------+ +---------+ 159 Figure 1: SFF enabled DHCP clients in service chaining 161 4. SFP DHCP Option Formats 163 The SFP information is composed of a generic SFP header, followed 164 by one or more SFP entries, as shown in Figure 2. 166 0 1 2 3 167 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 168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 169 | Version | Count | Reserved | 170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 | | 172 ~ ~ 173 | | 174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 176 Figure 2: SFP Information 178 Version: SFP Information version (0), 1 Octet. 179 Count: This field indicates total number of SFP entries. 180 This is 1 octet. 181 Reserved: MUST be set zero. 182 SFP Entries: One or more SFP entries, each composed Transport type, 183 Protocol ID, SP header (SPH) and followed by one or 184 more SFP-NH entries, as shown in Figure 3. 186 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 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 |Transport Type | Count | Protocol ID | 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 190 | Service Path (SP) Header | 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 192 | | 193 ~ ~ 194 | | 195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 197 Figure 3: SFP Entry 199 Transport Type: This field indicates the type of transport layer 200 attribute. Examples: L2, L3, L4. Values for transport type are 201 following: 203 ------------------------------------- 204 | Transport Types| Value(in decimal)| 205 ------------------------------------- 206 | L2 | 2 | 207 | L3 | 3 | 208 | L4 | 4 | 209 ------------------------------------- 210 Table 1: Transport Types 212 Count: This field indicates total number of SFP-NH entries 213 with the given Transport Type, Protocol ID and SP Header. 214 This is 1 octet. 216 Protocol ID: This field indicates the actual protocol layer 217 encapsulating the NSH. This is to be read and understood in 218 accordance with Transport Type field. Values for this field 219 are following: 221 ------------------------------------- 222 | Protocol ID | Value(in decimal)| 223 ------------------------------------- 224 | Ethernet | 35151 | 225 | VXLAN-gpe | 4790 | 226 | GRE | 47 | 227 | UDP | 6633 | 228 ------------------------------------- 229 Table 2: Protocol ID 231 Example of {Transport Type, Protocol ID} SHOULD be seen as 232 below: 234 ------------------------------------- 235 | Transport Type | Protocol ID | 236 ------------------------------------- 237 | 2 | 35151 | 238 | 2 | 4790 | 239 | 3 | 47 | 240 | 4 | 6633 | 241 ------------------------------------- 242 Table 3: Association of Transport 243 Type and Protocol ID 245 SP header is composed of Service Path ID and Service Index, 246 shown in Figure 4. 248 0 1 2 3 249 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 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 | Service Path ID | Service Index | 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 Figure 4: Service Function (SF) Header 255 Service Path ID (SPI): 24 bits 256 Service Index (SI): 8 bits 257 As defined in draft 258 [https://tools.ietf.org/html/draft-ietf-sfc-nsh-05#section-3.3] 260 SFP-NH Entries: One or more SFP-NH entries, as shown in Figure 5. 262 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 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 | SFP-NH Type | Count | Reserved | 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 | | 267 ~ ~ 268 | | 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 Figure 5: SFP-NH Entry 272 SFP-NH Type: Nexthop address types (1 Octet). 274 ------------------------------------- 275 | SFP-NH Type | Value (in decimal)| 276 ------------------------------------- 277 | IPv4 | 1 | 278 | IPv6 | 2 | 279 | Ethernet | 3 | 280 ------------------------------------- 281 Table 4: SFP-NH Type Values 283 Count: This field indicates total number of SFP-NH addresses 284 with the given SFP-NH type. This is 1 octet 285 Reserved: MUST be set zero. 286 SFP-NH addresses: One or more SFP nexthop addresses of same 287 SFP-NH type. 289 4.1 DHCPv4 Options 291 4.1.1 DHCPv4 NSH SFP Option 293 The NSH SFP option can be used by DHCP servers to communicate SFP 294 information to DHCPv4 clients, either in a stateful DHCPv4 address 295 configuration or renewal transaction, or in a stateless information 296 request (DHCPINFORM). 298 The format of NSH SFP option for DHCPv4 is: 300 0 1 2 3 301 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 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 | Code | Len | Reserved | 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 . . 306 . SFP Information . 307 . (variable length) . 308 . . 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 Figure 6: DHCPv4 NSH SFP option 313 Code: OPTION_NSH_SFP 314 (TBD1, 8 bit value, to be assigned by IANA). 316 Len: Length of SFP Information in 32 bit words. 318 Reserved: MUST be set zero. 320 SFP Info: Service function path details. 322 Refer Section 4 to see format and details of SFP information. 324 4.2 DHCPv6 Options 326 4.2.1 DHCPv6 NSH SFP Option 328 The NSH SFP option can be used by DHCPv6 servers to communicate SFP 329 information to DHCPv6 clients, either in a stateful DHCPv6 address 330 configuration or renewal transaction, or in a stateless information 331 request (Information-request). 333 The format of NSH SFP option for DHCPv6 is: 335 0 1 2 3 336 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 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 | OPTION_NSH_SFP | option-len | 339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 340 . . 341 . SFP Info . 342 . (variable length) . 343 . . 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 Figure 7: DHCPv6 NSH SFP option 348 option-code: OPTION_NSH_SFP 349 (TBD2, 16 bit value, to be assigned by IANA). 351 option-len: Length of SFP Information in octets. 353 SFP Info: Service function path details. 355 Refer section 4 to see format and details of SFP information. 357 5. Request and Processing DHCP SFP Option 359 In the service chaining model, SFF DHCP clients willing to participate 360 in SFP can request SFP information from the DHCP server using the 361 OPTION_NSH_SFP option. Details of this request in DHCPv4 and DHCPv6 362 are detailed in below sections. 364 5.1 DHCPv4 Client Behaviour 366 DHCPv4 client enabled with the capability of doing SFF/SF role in SFP 367 MUST request for SFP information in DHCPDISCOVER and DHCPREQUEST of 368 DHCPv4 protocol exchanges. Client behaviour is detailed below. 370 5.1.1 Requesting OPTION_NSH_SFP 372 SFF enabled DHCPv4 clients interested in SFP MUST send the 373 OPTION_NSH_SFP option to the DHCPv4 server along with other 374 options in Parameter Request List (PRL). DHCPv4 clients supporting this 375 option, should support FORCERENEW message exchange for any dynamic 376 updates in SFP from DHCPv4 server. 378 DHCP clients that support the SFF option must handle the case where 379 SFF functionality is configured after the client has been started. 380 This can be handled by the client either by renewing its lease when 381 SFF functionality is configured, or by sending a DHCPINFORM message. 383 5.2 DHCPv6 Client Behaviour 385 DHCPv6 client enabled with capability of doing SFF/SF role in SFP can 386 request for SFP information at different stages of DHCPv6 protocol 387 exchanges. Client behaviour is detailed below. 389 5.2.1 Requesting OPTION_NSH_SFP 391 SFF enabled DHCPv6 client interested in SFP MUST send the 392 OPTION_NSH_SFP option to the DHCPv6 server along with other 393 options in Option Request Option (ORO). 395 DHCPv6 clients that support the SFF option must handle the case where 396 SFF functionality is configured after the client has been started. 397 This can be handled by the client either by renewing its lease when 398 SFF functionality is configured, or by sending a Information-request 399 message. 401 DHCPv6 clients supporting this option, should support reconfigure 402 message exchange for any dynamic updates in SFP from DHCPv6 server. 404 5.3 DHCP Server Behaviour 406 DHCPv4 and DHCPv6 server if configured to provide service chaining 407 SFP parameters, SHOULD provision the SFF clients as per their 408 administrative policy. DHCPv4 and DHCPv6 server can receive request 409 for option OPTION_NSH_SFP from clients in Parameter Request List (PRL) 410 and Option Request Option (ORO) respectively. 412 When a DHCPv4 and DHCPv6 server has been configured with different 413 SFP parameters, the administrator or agent that updated the 414 configuration should trigger FORCERENEW/DHCPINFORM and Reconfigure 415 messages respectively for any DHCPv4 and DHCPv6 clients that now 416 have stale configurations. 418 5.3.1 Processing OPTION_NSH_SFP Request 420 Clients do not send OPTION_NSH_SFP to servers; therefore, servers 421 that receive this option should take no special action as a result 422 of having received it. 424 5.3.2 Notifying update in SFP path to SFF 426 Any update to notify about change in service chain path is notified 427 to SFF client using Reconfigure Message as defined in section 22.19 of 428 [RFC3315] for DHCPv6 and FORCERENEW message exchange as defined in 429 [RFC3203] of DHCPv4. 431 6. Security Considerations 433 Since there is no privacy protection for DHCP messages, an 434 eavesdropper who can monitor the link between the DHCP server and 435 requesting client can discover the SFP information. 437 To minimize the unintended exposure of SFP, the OPTION_NSH_SFP 438 option SHOULD be returned by DHCP servers only when the DHCP client 439 has requested this option in its request (Section 9.8 of [RFC2132]). 441 Networks where this option is used SHOULD use link-layer security and 442 integrity protection. Additionally, such networks should filter out 443 rogue DHCP messages (RFC 7610). 445 7. IANA Considerations 447 This document defines a new DHCP option, entitled "OPTION_NSH_SFP" 448 (see Section 4.1 and 4.2) for DHCPv4 and DHCPv6 respectively. Assigned a 449 value of TBD1 and TBD2 from the DHCPv4 [to be removed upon publication: 450 http://www.iana.org/assignments/bootp-dhcp-parameters] 451 [DHCP-OPTIONS] [DHCP-IANA] and DHCPv6 (Section 24.3 of RFC 3315) 452 option space defined respectively. 454 Tag Name Data Length Meaning 455 ---- ---- ------------ ------- 456 TBD1 OPTION_NSH_SFP 1 octet DHCPv4 NSH SFP option 457 TBD2 OPTION_NSH_SFP 2 octet DHCPv6 NSH SFP option 459 IANA is requested to create a new "DHCP NSH SFP parameters" registry. 460 The following sub-sections request new registries within the 461 "DHCP NSH SFP parameters" registry. 463 7.1 Transport types 465 -------------------------------------------------- 466 | Transport Type | Description | Reference | 467 -------------------------------------------------- 468 | 2 | L2 transports | This document | 469 | | | | 470 | 3 | L3 transports | This document | 471 | | | | 472 | 4 | L4 transports | This document | 473 -------------------------------------------------- 474 Table 5 476 7.2 SFP Nexthop types 478 ------------------------------------------------ 479 | SFP-NH Type | Description | Reference | 480 ------------------------------------------------ 481 | 1 | IPv4 | This document | 482 | | | | 483 | 2 | IPv6 | This document | 484 | | | | 485 | 3 | Ethernet | This document | 486 ------------------------------------------------ 487 Table 6 488 7.3 Protocol ID 490 Protocol ID values referenced in this draft Section 4, Table 2 is 491 more towards using the values and no action is required from IANA 492 towards it. 494 8. Acknowledgements 496 The authors would like to thank Ted Lemon, Youcef Laribi for the 497 constructive comments to initial draft. 499 9. References 501 9.1 Normative References 503 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 504 August 1980. 506 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 507 Requirement Levels", BCP 14, RFC 2119, March 1997. 509 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 510 RFC 2131, March 1997. 512 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP 513 Vendor Extensions", RFC 2132, March 1997. 515 [RFC2939] Droms, R., "Procedures and IANA Guidelines for 516 Definition of New DHCP Options and Message Types", 517 BCP 43, RFC 2939, September 2000. 519 [RFC3203] T'Joens, Y., Hublet, C., and P. De Schrijver, "DHCP 520 reconfigure extension", RFC 3203, December 2001. 522 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and M. 523 Carney, "Dynamic Host Configuration Protocol for IPv6", 524 July 2003. 526 [RFC6225] J. Polk., M. Linsner., M. Thomson., B. Aboba, Ed., 527 "Dynamic Host Configuration Protocol Options for 528 Coordinate-Based Location Configuration Information", 529 July 2011. 531 [I-D.ietf-sfc-nsh] 532 Quinn, P. and U. Elzur, "Network Service Header", draft- 533 ietf-sfc-nsh-00 (work in progress), March 2015. 535 9.2 Informative References 537 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 538 Cheshire, "Internet Assigned Numbers Authority (IANA) 539 Procedures for the Management of the Service Name and 540 Transport Protocol Port Number Registry", BCP 165, RFC 541 6335, August 2011. 543 [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, 544 L., Sridhar, T., Bursell, M., and C. Wright, "Virtual 545 eXtensible Local Area Network (VXLAN): A Framework for 546 Overlaying Virtualized Layer 2 Networks over Layer 3 547 Networks", RFC 7348, August 2014. 549 [RFC7610] F. Gont, W. Liu, G. Van de Velde, "DHCPv6-Shield: 550 Protecting against Rogue DHCPv6 Servers", BCP 199, 551 August 2015 553 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 554 Chaining (SFC) Architecture", RFC 7665, DOI 10.17487/ 555 RFC7665, October 2015, 556 . 558 [DHCP-OPTIONS] 559 Alexander, S. and R. Droms, "DHCP Options and 560 BOOTP Vendor Extensions", RFC 2132, March 1997. 562 [DHCP-IANA] 563 Droms, R., "Procedures and IANA Guidelines for 564 Definition of New DHCP Options and Message 565 Types", BCP 43, RFC 2939, September 2000. 567 [I-D.draft-ietf-sfc-control-plane-06] 568 Li, et al., "Service Function Chaining (SFC) Control Plane 569 Components & Requirements", 570 draft-ietf-sfc-control-plane-06 (work in progress), 571 May 2016. 573 Author's Address 575 Yogendra Pal 576 Cisco Systems, Inc. 577 Cessna Business Park, 578 Varthur Hobli, Outer Ring Road, 579 Bangalore, Karnataka 560103 580 India 582 EMail: yogpal@cisco.com 584 VenkataSubbaRao Gorrepati 585 Citrix R&D India Pvt Ltd, 586 Prestige Dynasty #33, Ulsoor Road 587 Bangalore, Karnataka 560042 588 India 590 EMail: venkatasubbarao.gorrepati@citrix.com 592 Vikram Menon 593 Ericsson India Global Services Pvt Ltd 594 Bangalore, Karnataka 595 India 597 EMail: vikram.menon@ericsson.com