idnits 2.17.1 draft-stein-pwe3-udp-00.txt: -(122): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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 3667, Section 5.1 on line 261. -- Found old boilerplate from RFC 3978, Section 5.5 on line 318. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 310), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 33. ** The document claims conformance with section 10 of RFC 2026, but uses some RFC 3978/3979 boilerplate. As RFC 3978/3979 replaces section 10 of RFC 2026, you should not claim conformance with it if you have changed to using RFC 3978/3979 boilerplate. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 7 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 3 instances of too long lines in the document, the longest one being 7 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 (July 11, 2004) is 7229 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) == Missing Reference: 'CE2E' is mentioned on line 108, but not defined == Missing Reference: 'RFC 2391' is mentioned on line 182, but not defined == Missing Reference: 'RFC 2979' is mentioned on line 183, but not defined == Missing Reference: 'FTP' is mentioned on line 210, but not defined == Unused Reference: 'L2TPv3' is defined on line 265, but no explicit reference was found in the text == Unused Reference: 'MPLS' is defined on line 268, but no explicit reference was found in the text == Unused Reference: 'PWCE2E' is defined on line 273, but no explicit reference was found in the text == Unused Reference: 'TCP' is defined on line 278, but no explicit reference was found in the text == Unused Reference: 'UDP' is defined on line 284, but no explicit reference was found in the text == Outdated reference: A later version (-15) exists of draft-ietf-l2tpext-l2tp-base-10 ** Downref: Normative reference to an Informational draft: draft-ietf-pwe3-arch (ref. 'PWE3-ARCH') -- Possible downref: Normative reference to a draft: ref. 'PWCE2E' ** Obsolete normative reference: RFC 793 (ref. 'TCP') (Obsoleted by RFC 9293) -- Possible downref: Non-RFC (?) normative reference: ref. 'VLAN' Summary: 14 errors (**), 0 flaws (~~), 13 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 PWE3 Y(J) Stein 2 Internet-Draft RAD Data Communications 3 Expires: January 9, 2005 July 11, 2004 5 UDP based PWs 6 draft-stein-pwe3-udp-00.txt 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC2026. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that 15 other groups may also distribute working documents as Internet- 16 Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at http:// 24 www.ietf.org/ietf/1id-abstracts.txt. 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 This Internet-Draft will expire on January 9, 2005. 31 Copyright Notice 33 Copyright (C) The Internet Society (2004). All Rights Reserved. 35 Abstract 37 The PWE3 charter permits three PSN types, namely "IP (both versions), 38 L2TP, or MPLS". The majority of drafts submitted to the working 39 group have focused on MPLS PSNs, and lesser attention has been given 40 to L2TPv3. Only the TDMoIP drafts have explicitly specified UDP/IP 41 as PSN, and only they stipulate the use of UDP port numbers as PW 42 labels. This draft discusses PWs based on UDP/IP, concentrating on 43 three issues, namely 1) the advisability of using UDP port numbers as 44 PW labels, 2) which UDP port number to use, and 3) what label 45 distribution protocol should be employed. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 2. Using UDP Port Numbers . . . . . . . . . . . . . . . . . . . . 4 51 3. Source or Destination Port . . . . . . . . . . . . . . . . . . 4 52 4. Port Number Distribution Protocol . . . . . . . . . . . . . . 6 53 5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 54 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 55 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 56 8. IPR Disclosure Acknowledgement . . . . . . . . . . . . . . . . 7 57 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 58 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 59 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 8 60 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 9 62 1. Introduction 64 Although sanctioned as a valid PSN by the PWE3 charter, little work 65 has been carried out concerning PWs over UDP/IP. In fact, use of 66 UDP/IP seems to be mentioned only in two WG drafts. 68 The PWE3 architecture draft [PWE3-ARCH] mentions the use of UDP, and 69 states: 71 PW Demultiplexing is provided by the PW label, which may take the 72 form specified in a number of IETF protocols, e.g. an MPLS label, 73 an L2TP session ID, or a UDP port number. 75 Of the service-specific drafts, only the TDMoIP drafts have 76 explicitly specified UDP/IP as PSN, and although these drafts have 77 stimulated much comment, their non-standard use of UDP ports has not 78 provoked discussion. 80 Unlike MPLS and L2TP, UDP/IP does not provide a transport tunneling 81 mechanism within which PWs are placed. However, UDP ports can 82 provide addressing functionality for the PWs themselves, by 83 populating a port field with the PW label. 85 The use of UDP ports as PW labels has been implemented by several 86 vendors, and is widely deployed for TDM PWs. The use of UDP/IP as 87 the PSN is particularly appropriate for CE to CE PWs [CE2E], since 88 the MPLS network is presently confined to the PEs. 90 This draft discusses PWs based on UDP/IP, concentrating on three 91 issues, namely 93 1) the fundamental advisability of using UDP port numbers as PW 94 labels, (see Section 2) 96 2) whether to place the PW label in source or destination port (see 97 Section 3), and 99 3) the label distribution protocol that should be employed (see 100 Section 4). 102 2. Using UDP Port Numbers 104 The majority of PWE drafts assume an MPLS (inner) label as PW label. 105 This is because most PWE work have focused on MPLS PSNs, as the basic 106 PWE architecture has been designed for service-provider scenarios. 107 MPLS is not presently available at end-user sites, and so MPLS-based 108 PWs are not directly applicable to CE-CE scenarios (but see [CE2E]). 109 In particular, enterprise applications where native services are 110 converted to IP at the customer premises, require PWs based on pure 111 IP, specifically UDP/IP. 113 The raison d'etre of the PW demultiplexer label is to allow multiple 114 PWs to be carried in a single tunnel, or for the UDP/IP case, between 115 two end systems. The PW label is situated in the packet overhead, 116 somewhere before the PWE3 Encapsulation Layer, and employs mechanisms 117 pre-existing in the PSN headers. 119 In addition to IP addresses, UDP/IP and TCP/IP employ 16-bit port 120 numbers. The allocation of port numbers is performed by IANA, with 121 �well known port numbers� in the range from 0 through 1023, 122 �registered port numbers� from 1024 through 49151, and �dynamic or 123 private port numbers� from 49152 through 65535. 125 As aforementioned, the architecture draft specifically allows the use 126 of UDP port numbers as PW labels. Since UDP always reserves space 127 for source and destination UDP port numbers, exploiting these fields 128 saves inserting additional overhead to the PW packet (as would be 129 required were L2TPv3 to be used). 131 3. Source or Destination Port 133 Unfortunately, the TCP and UDP standards themselves (RFCs 793 and 134 768, respectively) do not mandate methods for port number use. In 135 particular RFC 768 merely states: 137 Source Port is an optional field, when meaningful, 138 it indicates the port of the sending process, 139 and may be assumed to be the port to which a 140 reply should be addressed in the absence of any other information. 141 If not used, a value of zero is inserted. 143 Destination Port has a meaning within the context of a 144 particular Internet destination address. 146 While the TCP text is more descriptive, it is equally noncommittal: 148 To allow for many processes within a single Host to use TCP communication 149 facilities simultaneously, the TCP provides a set of addresses or ports 150 within each host. � 151 The binding of ports to processes is handled independently by each host. 152 However, it proves useful to attach frequently used processes � 153 to fixed sockets which are made known to the public. 154 These services can then be accessed through the known addresses. 155 Establishing and learning the port addresses of other processes 156 may involve more dynamic mechanisms. 158 The primary use of TCP and UDP port numbers is application 159 demultiplexing, with requests to an IP server being forwarded to the 160 appropriate application based on the well known or registered 161 destination port number. 163 VoIP and other RTP-based protocols [RTP] use the destination port for 164 connection demultiplexing, whereby multiple connections carrying data 165 destined for the same application are distinguished based on their 166 dynamic port numbers. Adopting this strategy would lead us to place 167 the PW label in the destination port. Such use excludes the capacity 168 to demultiplex applications based on the content of this port. While 169 this loss is not overly problematic, as sessions are setup in an 170 orderly way and packets do not arrive unexpected, this use 171 constitutes a break with tradition. 173 Using a port number field is superior to adding a non-standard field, 174 since available hardware components can switch based on these fields 175 in the IP header. Were we to desire maintaining the traditional use 176 of destination port as application demultiplexer, we could place the 177 PW label in the source port field. This is equally untraditional, 178 but exploits a 16-bit field that would otherwise be unused. It has 179 the additional advantage of begin compatible with enterprise 180 scenarios where NATs and firewalls are employed. 182 NAPT devices [RFC 2391] classify incoming packets based on 183 destination IP address and port number. Firewalls [RFC 2979] may use 184 source IP address as well. A server sitting behind a NAPT or 185 firewall may be accessed based on a known destination port number 186 resulting in packets being correctly routed. NAPT and firewalls that 187 adaptively learn mappings can function properly with dynamically 188 allocated destination port numbers, only when the connection 189 originator sits on their local side. 191 4. Port Number Distribution Protocol 193 A typical client-server protocol, such as telnet [TELNET], has the 194 server wait for an incoming connection by monitoring a well-known 195 port W. The client process, before initiating a connection, selects 196 an unused port number P. It then sends a packet to the server with 197 destination port W and source port P. The server�s responses are 198 sent using destination port P and source port W. Thus, a 199 bidirectional but asymmetric connections are established without any 200 explicit setup protocol. 202 This idea can be extended to the more symmetric case. For example, 203 in tftp [TFTP] both sides select identifiers, say P and Q. The 204 initiator sends a packet with destination port set to well-known port 205 W and source set to P. The response has destination P and source Q, 206 and only P and Q are used for the duration of the session. 208 In both of the above cases the port numbers were chosen by their 209 source (upstream allocation). Downstream allocation is also used, 210 for example by passive mode ftp [FTP]. Here the client issues a 211 command to a well-known port and the server responds with a message 212 containing the port number P to be used. 214 As an alternative to such implicit port number allocations, UDP/IP 215 PWs may be set up using an explicit control protocol. An obvious 216 possibility is the standard PWE control protocol based on targeted 217 LDP. This has the advantage of settling on a single control protocol 218 for all PW types except L2TPv3, and could be extended to additional 219 cases (e.g. allocation of VLAN tags [VLAN]). It has the shortcoming 220 of using LDP in a non-MPLS environment. Only minor changes would be 221 required to the LDP protocol for this use, mainly related to the 222 different label ranges (UDP port numbers are only 16 bits in length, 223 VLAN tags are 12 bits.) 225 5. Summary 227 The main questions raised in this draft are herein summarized. 229 Should UDP/IP PSNs, specified in the PWE charter and the architecture 230 draft, continue to be supported? 232 Should the PW label be placed in the source or destination UDP port? 233 Do we need registered port numbers for PWs? 235 What method should be used for label selection and distribution? 236 Should the label selection by upstream or downstream? Should an 237 implicit or explicit distribution protocol be used? Do we want to 238 standardize a single PWE control protocol? 240 6. Security Considerations 242 PWs do not enhance or detract from the security performance of the 243 underlying PSN, and PWs running over UDP/IP will suffer from the same 244 weaknesses as any other traffic on the same network. 246 PW labels used as UDP port numbers that are known or can be readily 247 surmised may pose security threats. 249 7. IANA Considerations 251 Depending on the label distribution protocol, use of UDP ports Will 252 require allocation of registered port numbers for the various PW 253 types. 0x085E (2142) has already been assigned by IANA to TDMoIP 254 PWs. 256 8. IPR Disclosure Acknowledgement 258 By submitting this Internet-Draft, we certify that any applicable 259 patent or other IPR claims of which we are aware have been disclosed, 260 and any of which we become aware will be disclosed, in accordance 261 with RFC 3668. 263 9. References 265 [L2TPv3] draft-ietf-l2tpext-l2tp-base-10.txt (08/03) Layer Two 266 Tunneling Protocol (L2TPv3), J. Lau et al., work in progress 268 [MPLS] RFC 3032 MPLS Label Stack encoding 270 [PWE3-ARCH] draft-ietf-pwe3-arch-07.txt (3/04), PWE3 Architecture, 271 Stewart Bryant et al, work in progress 273 [PWCE2E] draft-stein-pwe3-pwce2e-00.txt (3/04), Pseudowire Customer 274 Edge to Customer Edge Emulation, Y(J) Stein, work in progress 276 [RTP] RFC 3550 RTP: Transport Protocol for Real-Time Applications 278 [TCP] RFC 793 Transmission Control Protocol (TCP) 280 [TELNET] RFC 854 Telnet Protocol Specification 282 [TFTP] RFC 1350 The TFTP Protocol (Revision 2) 284 [UDP] RFC 768 User Datagram Protocol (UDP) 286 [VLAN] IEEE 802.1Q, IEEE Standards for Local and Metropolitan Area 287 Networks � Virtual Bridged Local Area Networks (2003) 289 10. Acknowledgments 291 The author would like to thank Sasha Vainshtein and Stewart Bryant 292 for interesting discussion and valuable contributions to the options 293 herein presented. 295 Author's Address 297 Yaakov (Jonathan) Stein 298 RAD Data Communications 299 24 Raoul Wallenberg St., Bldg C 300 Tel Aviv 69719 301 ISRAEL 303 Phone: +972 3 645-5389 304 EMail: yaakov_s@rad.com 306 Full Copyright Statement 308 Copyright (C) The Internet Society (2004). This document is subject 309 to the rights, licenses and restrictions contained in BCP 78, and 310 except as set forth therein, the authors retain all their rights. 312 This document and the information contained herein are provided on an 313 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 314 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 315 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 316 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 317 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 318 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 320 Acknowledgement 322 Funding for the RFC Editor function is currently provided by the 323 Internet Society.