PWE3 Y(J) Stein Internet-Draft RAD Data Communications Expires: January 9, 2005 July 11, 2004 UDP based PWs draft-stein-pwe3-udp-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on January 9, 2005. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract The PWE3 charter permits three PSN types, namely "IP (both versions), L2TP, or MPLS". The majority of drafts submitted to the working group have focused on MPLS PSNs, and lesser attention has been given to L2TPv3. Only the TDMoIP drafts have explicitly specified UDP/IP as PSN, and only they stipulate the use of UDP port numbers as PW labels. This draft discusses PWs based on UDP/IP, concentrating on three issues, namely 1) the advisability of using UDP port numbers as PW labels, 2) which UDP port number to use, and 3) what label distribution protocol should be employed. Stein Expires January 9, 2005 [Page 1] Internet-Draft UDP-PWs July 2004 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Using UDP Port Numbers . . . . . . . . . . . . . . . . . . . . 4 3. Source or Destination Port . . . . . . . . . . . . . . . . . . 4 4. Port Number Distribution Protocol . . . . . . . . . . . . . . 6 5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 8. IPR Disclosure Acknowledgement . . . . . . . . . . . . . . . . 7 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 8 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 9 Stein Expires January 9, 2005 [Page 2] Internet-Draft UDP-PWs July 2004 1. Introduction Although sanctioned as a valid PSN by the PWE3 charter, little work has been carried out concerning PWs over UDP/IP. In fact, use of UDP/IP seems to be mentioned only in two WG drafts. The PWE3 architecture draft [PWE3-ARCH] mentions the use of UDP, and states: PW Demultiplexing is provided by the PW label, which may take the form specified in a number of IETF protocols, e.g. an MPLS label, an L2TP session ID, or a UDP port number. Of the service-specific drafts, only the TDMoIP drafts have explicitly specified UDP/IP as PSN, and although these drafts have stimulated much comment, their non-standard use of UDP ports has not provoked discussion. Unlike MPLS and L2TP, UDP/IP does not provide a transport tunneling mechanism within which PWs are placed. However, UDP ports can provide addressing functionality for the PWs themselves, by populating a port field with the PW label. The use of UDP ports as PW labels has been implemented by several vendors, and is widely deployed for TDM PWs. The use of UDP/IP as the PSN is particularly appropriate for CE to CE PWs [CE2E], since the MPLS network is presently confined to the PEs. This draft discusses PWs based on UDP/IP, concentrating on three issues, namely 1) the fundamental advisability of using UDP port numbers as PW labels, (see Section 2) 2) whether to place the PW label in source or destination port (see Section 3), and 3) the label distribution protocol that should be employed (see Section 4). Stein Expires January 9, 2005 [Page 3] Internet-Draft UDP-PWs July 2004 2. Using UDP Port Numbers The majority of PWE drafts assume an MPLS (inner) label as PW label. This is because most PWE work have focused on MPLS PSNs, as the basic PWE architecture has been designed for service-provider scenarios. MPLS is not presently available at end-user sites, and so MPLS-based PWs are not directly applicable to CE-CE scenarios (but see [CE2E]). In particular, enterprise applications where native services are converted to IP at the customer premises, require PWs based on pure IP, specifically UDP/IP. The raison d'etre of the PW demultiplexer label is to allow multiple PWs to be carried in a single tunnel, or for the UDP/IP case, between two end systems. The PW label is situated in the packet overhead, somewhere before the PWE3 Encapsulation Layer, and employs mechanisms pre-existing in the PSN headers. In addition to IP addresses, UDP/IP and TCP/IP employ 16-bit port numbers. The allocation of port numbers is performed by IANA, with ôwell known port numbersö in the range from 0 through 1023, ôregistered port numbersö from 1024 through 49151, and ôdynamic or private port numbersö from 49152 through 65535. As aforementioned, the architecture draft specifically allows the use of UDP port numbers as PW labels. Since UDP always reserves space for source and destination UDP port numbers, exploiting these fields saves inserting additional overhead to the PW packet (as would be required were L2TPv3 to be used). 3. Source or Destination Port Unfortunately, the TCP and UDP standards themselves (RFCs 793 and 768, respectively) do not mandate methods for port number use. In particular RFC 768 merely states: Source Port is an optional field, when meaningful, it indicates the port of the sending process, and may be assumed to be the port to which a reply should be addressed in the absence of any other information. If not used, a value of zero is inserted. Destination Port has a meaning within the context of a particular Internet destination address. Stein Expires January 9, 2005 [Page 4] Internet-Draft UDP-PWs July 2004 While the TCP text is more descriptive, it is equally noncommittal: To allow for many processes within a single Host to use TCP communication facilities simultaneously, the TCP provides a set of addresses or ports within each host. à The binding of ports to processes is handled independently by each host. However, it proves useful to attach frequently used processes à to fixed sockets which are made known to the public. These services can then be accessed through the known addresses. Establishing and learning the port addresses of other processes may involve more dynamic mechanisms. The primary use of TCP and UDP port numbers is application demultiplexing, with requests to an IP server being forwarded to the appropriate application based on the well known or registered destination port number. VoIP and other RTP-based protocols [RTP] use the destination port for connection demultiplexing, whereby multiple connections carrying data destined for the same application are distinguished based on their dynamic port numbers. Adopting this strategy would lead us to place the PW label in the destination port. Such use excludes the capacity to demultiplex applications based on the content of this port. While this loss is not overly problematic, as sessions are setup in an orderly way and packets do not arrive unexpected, this use constitutes a break with tradition. Using a port number field is superior to adding a non-standard field, since available hardware components can switch based on these fields in the IP header. Were we to desire maintaining the traditional use of destination port as application demultiplexer, we could place the PW label in the source port field. This is equally untraditional, but exploits a 16-bit field that would otherwise be unused. It has the additional advantage of begin compatible with enterprise scenarios where NATs and firewalls are employed. NAPT devices [RFC 2391] classify incoming packets based on destination IP address and port number. Firewalls [RFC 2979] may use source IP address as well. A server sitting behind a NAPT or firewall may be accessed based on a known destination port number resulting in packets being correctly routed. NAPT and firewalls that adaptively learn mappings can function properly with dynamically allocated destination port numbers, only when the connection originator sits on their local side. Stein Expires January 9, 2005 [Page 5] Internet-Draft UDP-PWs July 2004 4. Port Number Distribution Protocol A typical client-server protocol, such as telnet [TELNET], has the server wait for an incoming connection by monitoring a well-known port W. The client process, before initiating a connection, selects an unused port number P. It then sends a packet to the server with destination port W and source port P. The serverÆs responses are sent using destination port P and source port W. Thus, a bidirectional but asymmetric connections are established without any explicit setup protocol. This idea can be extended to the more symmetric case. For example, in tftp [TFTP] both sides select identifiers, say P and Q. The initiator sends a packet with destination port set to well-known port W and source set to P. The response has destination P and source Q, and only P and Q are used for the duration of the session. In both of the above cases the port numbers were chosen by their source (upstream allocation). Downstream allocation is also used, for example by passive mode ftp [FTP]. Here the client issues a command to a well-known port and the server responds with a message containing the port number P to be used. As an alternative to such implicit port number allocations, UDP/IP PWs may be set up using an explicit control protocol. An obvious possibility is the standard PWE control protocol based on targeted LDP. This has the advantage of settling on a single control protocol for all PW types except L2TPv3, and could be extended to additional cases (e.g. allocation of VLAN tags [VLAN]). It has the shortcoming of using LDP in a non-MPLS environment. Only minor changes would be required to the LDP protocol for this use, mainly related to the different label ranges (UDP port numbers are only 16 bits in length, VLAN tags are 12 bits.) 5. Summary The main questions raised in this draft are herein summarized. Should UDP/IP PSNs, specified in the PWE charter and the architecture draft, continue to be supported? Should the PW label be placed in the source or destination UDP port? Do we need registered port numbers for PWs? What method should be used for label selection and distribution? Should the label selection by upstream or downstream? Should an implicit or explicit distribution protocol be used? Do we want to standardize a single PWE control protocol? Stein Expires January 9, 2005 [Page 6] Internet-Draft UDP-PWs July 2004 6. Security Considerations PWs do not enhance or detract from the security performance of the underlying PSN, and PWs running over UDP/IP will suffer from the same weaknesses as any other traffic on the same network. PW labels used as UDP port numbers that are known or can be readily surmised may pose security threats. 7. IANA Considerations Depending on the label distribution protocol, use of UDP ports Will require allocation of registered port numbers for the various PW types. 0x085E (2142) has already been assigned by IANA to TDMoIP PWs. 8. IPR Disclosure Acknowledgement By submitting this Internet-Draft, we certify that any applicable patent or other IPR claims of which we are aware have been disclosed, and any of which we become aware will be disclosed, in accordance with RFC 3668. Stein Expires January 9, 2005 [Page 7] Internet-Draft UDP-PWs July 2004 9. References [L2TPv3] draft-ietf-l2tpext-l2tp-base-10.txt (08/03) Layer Two Tunneling Protocol (L2TPv3), J. Lau et al., work in progress [MPLS] RFC 3032 MPLS Label Stack encoding [PWE3-ARCH] draft-ietf-pwe3-arch-07.txt (3/04), PWE3 Architecture, Stewart Bryant et al, work in progress [PWCE2E] draft-stein-pwe3-pwce2e-00.txt (3/04), Pseudowire Customer Edge to Customer Edge Emulation, Y(J) Stein, work in progress [RTP] RFC 3550 RTP: Transport Protocol for Real-Time Applications [TCP] RFC 793 Transmission Control Protocol (TCP) [TELNET] RFC 854 Telnet Protocol Specification [TFTP] RFC 1350 The TFTP Protocol (Revision 2) [UDP] RFC 768 User Datagram Protocol (UDP) [VLAN] IEEE 802.1Q, IEEE Standards for Local and Metropolitan Area Networks ù Virtual Bridged Local Area Networks (2003) 10. Acknowledgments The author would like to thank Sasha Vainshtein and Stewart Bryant for interesting discussion and valuable contributions to the options herein presented. Author's Address Yaakov (Jonathan) Stein RAD Data Communications 24 Raoul Wallenberg St., Bldg C Tel Aviv 69719 ISRAEL Phone: +972 3 645-5389 EMail: yaakov_s@rad.com Stein Expires January 9, 2005 [Page 8] Internet-Draft UDP-PWs July 2004 Full Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Stein Expires January 9, 2005 [Page 9]