idnits 2.17.1 draft-miles-dhc-dhcpv6-ldra-02.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 20. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 643. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 654. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 661. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 667. 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 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 (November 18, 2008) is 5632 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) == Outdated reference: A later version (-06) exists of draft-ietf-dhc-l2ra-02 Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DHC Working Group D. Miles, Ed. 3 Internet-Draft S. Ooghe 4 Intended status: Informational Alcatel-Lucent 5 Expires: May 22, 2009 W. Dec 6 Cisco Systems 7 S. Krishnan 8 A. Kavanagh 9 Ericsson 10 November 18, 2008 12 Lightweight DHCPv6 Relay Agent (LDRA) 13 draft-miles-dhc-dhcpv6-ldra-02 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on May 22, 2009. 40 Abstract 42 This document proposes a Lightweight DHCPv6 Relay Agent (LDRA) that 43 is used to insert relay agent options in DHCPv6 message exchanges 44 identifying client-facing interfaces. The LDRA can be implemented in 45 existing access nodes (such as DSLAMs and Ethernet switches) that do 46 not support IPv6 control or routing functions. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 52 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 4. Message Format . . . . . . . . . . . . . . . . . . . . . . . . 4 55 4.1. Relay-Forward Message . . . . . . . . . . . . . . . . . . 5 56 4.2. Relay-Reply Message . . . . . . . . . . . . . . . . . . . 5 57 4.3. Mandatory DHCP Options . . . . . . . . . . . . . . . . . . 5 58 4.3.1. Relay-Message Option . . . . . . . . . . . . . . . . . 5 59 4.3.2. Interface-ID Option . . . . . . . . . . . . . . . . . 6 60 5. Agent Behaviour . . . . . . . . . . . . . . . . . . . . . . . 6 61 5.1. Relaying a Client Message . . . . . . . . . . . . . . . . 6 62 5.1.1. Client Message Validation . . . . . . . . . . . . . . 7 63 5.1.2. Trusted and Untrusted Interfaces . . . . . . . . . . . 7 64 5.2. Relaying a Relay-Reply message from the network . . . . . 8 65 6. Network Topology . . . . . . . . . . . . . . . . . . . . . . . 9 66 6.1. Client and Server on Same Link . . . . . . . . . . . . . . 9 67 6.2. Client and Server behind Relay Agent . . . . . . . . . . . 10 68 6.3. Relay Agent in Front of LDRA . . . . . . . . . . . . . . . 11 69 7. Server Considerations . . . . . . . . . . . . . . . . . . . . 12 70 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 12 71 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 72 10. Security Considerations . . . . . . . . . . . . . . . . . . . 13 73 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 74 11.1. Normative References . . . . . . . . . . . . . . . . . . . 13 75 11.2. Informative References . . . . . . . . . . . . . . . . . . 13 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 77 Intellectual Property and Copyright Statements . . . . . . . . . . 16 79 1. Introduction 81 DHCPv6 Relay-Agents [RFC3315] are deployed to forward DHCPv6 messages 82 between clients and servers when they are not on the same IPv6 link 83 and are often implemented alongside a routing function in a common 84 node. A Lightweight DHCPv6 Relay Agent (LDRA) allows Relay Agent 85 Information to be inserted by an access node that performs a link- 86 layer bridging (i.e. non-routing) function. A LDRA resides on the 87 same IPv6 link as the client and a DHCPv6 Relay Agent or Server and 88 is functionally the equivalent of the Layer 2 DHCP Relay draft[L2RA] 89 proposed for DHCPv4 operation. 91 Unlike a DHCPv6 Relay-Agent specified in [RFC3315], a LDRA does not 92 implement any IPv6 control functions (e.g. ICMPv6) or have any 93 routing capability in the node. 95 1.1. Requirements Language 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 99 document are to be interpreted as described in RFC 2119 [RFC2119]. 101 2. Background 103 A variety of different link-layer network topologies exist for the 104 aggregation of IPv6 nodes into one or more routers. In Layer 2 105 aggregation networks (IEEE 802.1D bridging or similar) that have many 106 nodes on a single link, a DHCPv6 server or DHCP relay agent would 107 normally be unaware of how a DHCP client is attached to the network. 108 The LDRA allows Relay Agent Information, including the Interface-ID 109 option [RFC3315], to be inserted by the access node so that it may be 110 used by the DHCPv6 server for client identification. A typical 111 application in a broadband service provider may be as an equivalent 112 to the Broadband Forum TR-101 Layer 2 DHCP Relay Agent[TR-101] 113 described in [L2RA] 115 3. Terminology 117 Address An IP layer identifier for an interface or 118 set of interfaces 120 Host A non-routing IPv6 node that is 121 participating in DHCPv6 message exchange 123 IP Internet Protocol Version 6 (IPv6) 125 LDRA Lightweight DHCPv6 Relay Agent 127 Link A communication facility or medium over 128 which nodes can communicate at the link 129 layer 131 Link-local address An IP address having only local-scope, 132 indicated by having the address prefix 133 FE80::/10, that can be used to reach 134 neighbouring nodes attached to the same 135 link. Every interface has a link-local 136 address. 138 Node A device that implements IPv6 140 Router A node that forwards packets not directly 141 addressed to itself 143 Access Node A device that combines many interfaces onto 144 one link. An access node is not IP-aware 145 in the data path 147 Relay Agent A node that acts as an intermediary to 148 deliver DHCP messages between clients and 149 servers and being on the same link as the 150 client 152 Lightweight Relay Agent A function on the access node that 153 intercepts DHCP messages between clients 154 and servers. The function exists as a bump 155 in the wire on the IP link. 157 Unspecified address An IP address that is comprised entirely of 158 zeros 160 4. Message Format 162 The Lightweight DHCPv6 Relay Agent (LDRA) exchanges DHCP messages 163 between clients and servers using the message formats established in 164 [RFC3315]. 166 To maintain interoperability with existing DHCP relays and servers 167 the message format is unchanged from [RFC3315]. The LDRA implements 168 the same message types as a normal DHCPv6 Relay Agent. They are: 170 o Relay-Forward Messages 172 o Relay-Reply Messages 174 4.1. Relay-Forward Message 176 The Relay-Forward message is created by any DHCPv6 Relay Agent, 177 including an LDRA, to forward messages between clients and servers or 178 other relay agents. These messages are built as specified in 179 [RFC3315] 181 The Relay-Forward message contains relay agent parameters that 182 identify the client-facing interface on which any reply messages 183 should be forwarded. These parameters are link-address, peer-address 184 and Interface-ID. The link-address parameter MUST be set to the 185 unspecified address. The Interface-ID Relay Agent Option MUST be 186 included in the Relay-Forward message. The LDRA MAY insert 187 additional relay agent options. 189 4.2. Relay-Reply Message 191 The Relay-Reply message is constructed by a DHCPv6 server to send 192 parameters to a DHCP client when a relay agent is present between the 193 server and the client. The Relay-Reply message may be sent after an 194 initial Relay-Forward message as the parameters link-address, peer- 195 address, Interface-ID and the relay agent's IP address are learnt 196 from the Relay-Forward message. 198 The server MUST include the Interface-ID option in the Relay-Reply 199 Message to indicate to the LDRA the interface on which the de- 200 capsulated message should be forwarded. 202 4.3. Mandatory DHCP Options 204 Parameters are exchanged between DHCP client, relay-agent and server 205 through the use of DHCP options. There are a set of mandatory DHCP 206 options that MUST be included by the LDRA in all Relay-Forward and 207 Relay-Reply messages. These are the: 209 o Relay-Message Option 211 o Interface-ID Option 213 4.3.1. Relay-Message Option 215 A DHCPv6 Relay Agent relays messages between clients and servers or 216 other relay agents through Relay-Forward and Relay-Reply message 217 types. The original client DHCP message (i.e. the packet payload, 218 excluding UDP and IP headers) is encapsulated in a Relay Message 219 option [RFC3315]. 221 As an LDRA does not implement ICMPv6, fragmentation of Relay-Messages 222 is not supported. If a Relay-Message would exceed the MTU of the 223 outgoing interface it MUST be discarded and an error condition SHOULD 224 be logged. 226 4.3.2. Interface-ID Option 228 The LDRA MUST include the Interface-ID option [RFC3315] in all Relay- 229 Forward messages. When a LDRA receives a Relay-reply message with an 230 Interface-ID option present and link-address unspecified, the LDRA 231 MUST relay the decapsulated message to the client on the interface 232 identified in the Interface-ID option. 234 Servers MAY use the Interface-ID for parameter assignment policies. 235 The format of the Interface-ID is outside the scope of this 236 contribution. The Interface-ID SHOULD be considered an opaque value, 237 i.e. the server SHOULD NOT try to parse the contents of the 238 Interface-ID option. The LDRA SHOULD use the same Interface-ID value 239 for a given interface, and this value SHOULD be retained across 240 restarts. This is because, if the Interface-ID changes, a server 241 will not be able to use it reliably in parameter assignment policies. 243 5. Agent Behaviour 245 The LDRA MUST have each of its interfaces configured as either 246 client-facing or network (DHCPv6 server) facing. The LDRA uses the 247 notion of client-facing and network-facing interfaces to process the 248 DHCPv6 messages. 250 5.1. Relaying a Client Message 252 When a DHCPv6 message (defined in [RFC3315]) is received on any 253 client-facing interface, the LDRA MUST intercept and process the 254 message. The LDRA MUST also prevent the original message from being 255 forwarded on the network facing interface. 257 The lightweight relay agent adds any other options it is configured 258 or required to include in the Relay-Forward message. The LDRA MUST 259 set the link-address field of the Relay-forward message to the 260 Unspecified Address (::) and MUST include the Interface-ID option in 261 all DHCP Relay-Forward messages. 263 If the message received on the client-facing interface is a Relay- 264 Forward message, the LDRA MUST set the Hop-Count field in the newly 265 created Relay-Forward message to the value of the hop-count field in 266 the received message incremented by 1 as specified in [RFC3315]. 268 The LDRA MUST copy the IP destination and link-layer destination 269 addresses from the client-originated message into the IP destination 270 address and link-layer destination address of the Relay-forward 271 message. 273 The LDRA MUST copy the IP source address from the client-originated 274 message into the peer-address field of the Relay-forward message. 275 The LDRA MUST copy the link-layer source address from the client- 276 originated message into the link-layer source address of the Relay- 277 forward message. 279 5.1.1. Client Message Validation 281 On receipt of a DHCP message on the client facing interface, the LDRA 282 MUST discard a message if it is of one of following message types: 284 o ADVERTISE (2) 286 o REPLY (7) 288 o RECONFIGURE (10) 290 o RELAY-REPLY (13) 292 Options contained in the DHCPv6 message MUST NOT be validated by the 293 LDRA, making it the responsibility of the DHCP server to check 294 message option validity and allow new options to be introduced 295 without changes on the LDRA. 297 5.1.2. Trusted and Untrusted Interfaces 299 In [RFC3046] DHCPv4 relay-agents had their client-facing interfaces 300 set to trusted and untrusted. An LDRA MUST implement a trusted/ 301 untrusted definition for all client-facing interfaces that SHOULD be 302 configurable per interface. When a client-facing interface is deemed 303 untrusted the LDRA MUST discard any message received from the client- 304 facing interface of type RELAY-FORWARD (12). 306 In DHCPv4 it was not possible for a DHCP server to determine whether 307 the client or an intermediate relay agent had added relay agent 308 options and thus trusted interfaces (relay-agent interfaces that 309 would allow any DHCP options to be present on incoming messages) and 310 untrusted interfaces (relay-agent interfaces that would ensure there 311 are no relay-agent options on incoming messages) were defined. In 312 DHCPv6, relay agents encapsulate the received message into the Relay- 313 Message Option in addition to adding any relay-agent options. This 314 nested message behaviour allows a server to identify the options each 315 relay-agent has inserted along the path, whenever the data path 316 between LDRA and server falls within a protected or operator 317 controlled environment. 319 When an LDRA is deployed, DHCPv6 servers MAY be configured with the 320 Relay-Forward hop-count of the LDRA to instruct at which level of 321 nesting the relay-agent options should be parsed. This removes the 322 need for an interface to be configured as trusted or untrusted by 323 providing the DHCPv6 server with an awareness of the LDRA logical 324 location in the DHCP relay path. This behaviour is dependent on the 325 interception of all DHCP messages by the LDRA and the incrementing of 326 the Relay-Forward hop-count if a Relay-Forward message is received 327 from the client-facing LDRA interface. 329 5.2. Relaying a Relay-Reply message from the network 331 When a valid Relay-Reply is received on any network-facing access 332 node interface, it MUST be intercepted by the LDRA. The LDRA MUST 333 listen to all IP traffic that has a link-local scoped source address, 334 link-local scoped destination address, protocol type UDP and 335 destination port 547. The LDRA SHOULD ignore any message that does 336 not meet this criteria and MUST allow it to be forwarded like any 337 other packet. The LDRA MAY be configured to listen only to a 338 specific destination address if it has been configured as a node 339 (implementing a full IP stack). 341 The LDRA MUST intercept and process all DHCP Relay-Reply messages and 342 MUST silently discard all other DHCP message types. 344 In addition to the validity checks performed by a relay agent in 345 [RFC3315] , the Relay-Reply message is considered valid by the LDRA 346 if: 348 - The Interface-ID Option is present and the value corresponds to a 349 valid interface in the access node, 351 - the Relay-Reply peer-address and the destination IP address MUST be 352 identical and MUST be a link-local scoped address when no IP address 353 is configured on the LDRA, and 355 - the link-address is the Unspecified Address when no IP address is 356 configured on the LDRA 358 The LDRA copies the peer-address into the destination IP address 359 field, and MAY use the destination link-layer address (MAC address) 360 or Interface-ID to determine which interface to send the message to 361 the client. The contents of the Relay Message Option is put into an 362 IP/UDP packet and then forwarded to the client. 364 The LDRA MUST copy the link-layer and IP source address from the 365 Relay-Reply message into the IP/UDP packet that is forwarded to the 366 client. 368 6. Network Topology 370 The LDRA intercepts any DHCPv6 message received on client-facing 371 interfaces with a destination IP address of 372 All_DHCP_Relay_Agents_and_Servers (FF02::1:2). The LDRA MUST NOT 373 forward the original client message to a network-facing interface, it 374 MUST process the message and add the appropriate Relay-Forward 375 options as described in previous sections. 377 6.1. Client and Server on Same Link 379 The access node acts as a bridge; it has no information about any IP 380 prefixes that are valid on the link, thus a server should consider 381 address and parameter assignment as if the client DHCP message was 382 not relayed. 383 +--------+ 384 Client -------| | 385 | Access | 386 Client -------| Node |-----+ 387 | (LDRA) | | 388 Client -------| | | 389 +--------+ | 390 | +--------+ 391 |------| Server | 392 | +--------+ 393 +--------+ | 394 Client -------| | | 395 | Access | | 396 Client -------| Node |-----+ 397 | (LDRA) | 398 Client -------| | 399 +--------+ 401 <------IPv6 Link-----> 403 For example, if a client sent a DHCP solicit message that was relayed 404 by the LDRA and then to the server, the server would receive the 405 following Relay-Forward message from the LDRA: 407 src-ip: client link-local address 408 dst-ip: All_DHCP_Relay_Agents_and_Servers 409 msg-type: RELAY-FORWARD 410 hop-count: 0 411 link-address: Unspecified_Address 412 peer-address: client link-local address 413 Interface-ID Option: 414 interface-id: LDRA-inserted interface-id 415 Relay-Message Option, which contains: 416 msg-type: SOLICIT 417 Solicit Message Options: 419 6.2. Client and Server behind Relay Agent 421 The client and server are on different IPv6 links, separated by one 422 or more relay agents that will typically act as a router. The LDRA 423 will send Relay-Forward messages upstream towards the second relay 424 agent which in turn will process the messages. 425 +--------+ 426 Client -------| | 427 | Access | 428 Client -------| Node |-----+ 429 | (LDRA) | | 430 Client -------| | | 431 +--------+ | 432 | +--------+ +--------+ 433 |------| RelayB |---------| Server | 434 | +--------+ +--------+ 435 +--------+ | 436 Client -------| | | 437 | Access | | 438 Client -------| Node |-----+ 439 | (LDRA) | 440 Client -------| | 441 +--------+ 443 <--IPv6 Link A--> <--IPv6 Link B--> 445 For example, if a client sent a DHCP solicit message that was relayed 446 by the LDRA to another relay agent and then to the server, the server 447 would receive the following Relay-Forward message from the LDRA: 449 src-ip: relayB 450 dst-ip: server 451 msg-type: RELAY-FORWARD 452 hop-count: 1 453 link-address: relayB address from link A 454 peer-address: client link-local address 455 Relay-Message Option, which contains: 456 msg-type: RELAY-FORWARD 457 hop-count: 0 458 link-address: Unspecified_Address 459 peer-address: client link-local address 460 Interface-ID Option: 461 interface-id: LDRA-inserted interface-id 462 Relay-Message Option, which contains: 463 msg-type: SOLICIT 464 Solicit Message Options: 466 6.3. Relay Agent in Front of LDRA 468 The client and server are on different IPv6 links, separated by one 469 or more relay agents that will typically act as a router and there is 470 an [RFC3315] Relay Agent on the client-facing Interface of the LDRA. 471 The LDRA will send Relay-Forward messages upstream towards the second 472 relay agent which in turn will process the messages. 473 +--------+ 474 RelayC -------| | 475 | Access | 476 RelayC -------| Node |-----+ 477 | (LDRA) | | 478 RelayC -------| | | 479 +--------+ | 480 | +--------+ +--------+ 481 |------| RelayB |---------| Server | 482 | +--------+ +--------+ 483 +--------+ | 484 RelayC -------| | | 485 | Access | | 486 RelayC -------| Node |-----+ 487 | (LDRA) | 488 RelayC -------| | 489 +--------+ 491 <--IPv6 Link A--> <--IPv6 Link B--> 493 For example, if a client sent a DHCP solicit message that was relayed 494 by the LDRA to another relay agent and then to the server, the server 495 would receive the following Relay-Forward message from the LDRA: 497 src-ip: relayB 498 dst-ip: server 499 msg-type: RELAY-FORWARD 500 hop-count: 2 501 link-address: relayB address from link A 502 peer-address: relayC 503 Relay-Message Option, which contains: 504 msg-type: RELAY-FORWARD 505 hop-count: 1 506 link-address: Unspecified_Address 507 peer-address: relayC 508 Interface-ID Option: 509 interface-id: LDRA-inserted interface-id 510 Relay-Message Option, which contains: 511 msg-type: RELAY-FORWARD 512 hop-count: 0 513 link-address: global or unspecified address 514 peer-address: end client address 515 Interface-ID Option: (if required) 516 interface-id: relayC inserted Interface-ID 517 Relay-Message Option, which contains: 518 msg-type: SOLICIT 519 Solicit Message Options: 521 7. Server Considerations 523 Although permitted in [RFC3315] the LDRA makes specific use of Relay- 524 Forward link-address fields with a zero value. 526 o A DHCPv6 server MUST ignore any Relay-Forward link-addresses field 527 with a zero value in Relay-Forward messages when searching for the 528 inner-most link-address field. This allows the DHCPv6 server to 529 select an address appropriate to the L3 link and supports a 530 combination of L3 DHCPv6 relay agents and LDRA. 532 o If no non-zero Relay-Forward link-address is found, the DHCPv6 533 server should act as though the message were directly received. 534 This is the case where no LDRA is present. 536 8. Contributors 538 The authors would like to thank the following for their support, 539 Lieven Levrau, Alastair Johnson, Robert Haylock, Mickey Vucic, Ludwig 540 Pauwels, Fernando Cuervo, John Kaippallimalil, Fredrik Garneij and 541 Alfred Hoenes. 543 Comments are solicited and should be addressed to the DHC WG mailing 544 list (dhcwg@ietf.org) and/or the author. 546 9. IANA Considerations 548 This document does not introduce any new namespaces for the IANA to 549 manage. 551 10. Security Considerations 553 Although the LDRA only listens to client-originated IPv6 traffic sent 554 to the All_DHCPv6_Servers_and_Relay_Agents address on UDP port 547, 555 the LDRA SHOULD implement some form of rate-limiting on received 556 messages to prevent excessive process utilisation. As DHCP is 557 session-oriented, messages in excess of the rate-limit may be 558 silently discarded. 560 The hop count based determination of the trustworthiness of the LDRA 561 can be easily defeated by a rogue relay agent on the network-facing 562 interface of the LDRA. 564 11. References 566 11.1. Normative References 568 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 569 Requirement Levels", RFC 2119, March 1997. 571 [RFC3315] Droms, R., "Dynamic Host Configuration Protocol for IPv6 572 (DHCPv6)", RFC 3315, July 2003. 574 11.2. Informative References 576 [L2RA] Joshi, B., "Layer 2 Relay Agent Information", IETF 577 Draft draft-ietf-dhc-l2ra-02, May 2008. 579 [RFC3046] Patrick, M., "DHCP Relay Agent Information Option", 580 RFC 3046, January 2001. 582 [TR-101] The Broadband Forum, "Migration to Ethernet-Based DSL 583 Aggregation", Technical Report TR-101, April 2006. 585 Authors' Addresses 587 David Miles (editor) 588 Alcatel-Lucent 589 L3 / 215 Spring St 590 Melbourne, Victoria 3000 591 Australia 593 Phone: +61 3 9664 3308 594 Email: david.miles@alcatel-lucent.com 596 Sven Ooghe 597 Alcatel-Lucent 598 Copernicuslaan 50 599 2018 Antwerp, 600 Belgium 602 Phone: 603 Email: sven.ooghe@alcatel-lucent.com 605 Wojciech Dec 606 Cisco Systems 607 Haarlerberdweg 13-19 608 1101 CH Amsterdam, 609 The Netherlands 611 Phone: 612 Email: wdec@cisco.com 614 Suresh Krishnan 615 Ericsson 616 8400 Blvd Decarie 617 Town of Mount Royal, Quebec 618 Canada 620 Email: suresh.krishnan@ericsson.com 621 Alan Kavanagh 622 Ericsson 623 8400 Blvd Decarie 624 Town of Mount Royal, Quebec 625 Canada 627 Email: alan.kavanagh@ericsson.com 629 Full Copyright Statement 631 Copyright (C) The IETF Trust (2008). 633 This document is subject to the rights, licenses and restrictions 634 contained in BCP 78, and except as set forth therein, the authors 635 retain all their rights. 637 This document and the information contained herein are provided on an 638 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 639 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 640 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 641 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 642 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 643 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 645 Intellectual Property 647 The IETF takes no position regarding the validity or scope of any 648 Intellectual Property Rights or other rights that might be claimed to 649 pertain to the implementation or use of the technology described in 650 this document or the extent to which any license under such rights 651 might or might not be available; nor does it represent that it has 652 made any independent effort to identify any such rights. Information 653 on the procedures with respect to rights in RFC documents can be 654 found in BCP 78 and BCP 79. 656 Copies of IPR disclosures made to the IETF Secretariat and any 657 assurances of licenses to be made available, or the result of an 658 attempt made to obtain a general license or permission for the use of 659 such proprietary rights by implementers or users of this 660 specification can be obtained from the IETF on-line IPR repository at 661 http://www.ietf.org/ipr. 663 The IETF invites any interested party to bring to its attention any 664 copyrights, patents or patent applications, or other proprietary 665 rights that may cover technology that may be required to implement 666 this standard. Please address the information to the IETF at 667 ietf-ipr@ietf.org.