idnits 2.17.1 draft-van-beijnum-behave-ftp64-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 : ---------------------------------------------------------------------------- == There are 3 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 19, 2009) is 5302 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) -- Obsolete informational reference (is this intentional?): RFC 2765 (Obsoleted by RFC 6145) == Outdated reference: A later version (-05) exists of draft-liu-behave-ftp64-03 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Behavior Engineering for Hindrance I. van Beijnum 3 Avoidance IMDEA Networks 4 Internet-Draft October 19, 2009 5 Intended status: Standards Track 6 Expires: April 22, 2010 8 IPv6-to-IPv4 translation FTP considerations 9 draft-van-beijnum-behave-ftp64-06 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on April 22, 2010. 34 Copyright Notice 36 Copyright (c) 2009 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents in effect on the date of 41 publication of this document (http://trustee.ietf.org/license-info). 42 Please review these documents carefully, as they describe your rights 43 and restrictions with respect to this document. 45 Abstract 47 The File Transfer Protocol has a very long history, and despite the 48 fact that today, other options exist to perform file transfers, FTP 49 is still in common use. As such, it is important that in the 50 situation where some client computers are IPv6-only while many 51 servers are still IPv4-only and IPv6-to-IPv4 translators are used to 52 bridge that gap, FTP is made to work through these translators as 53 best it can. 55 FTP has an active and a passive mode, both as original commands that 56 are IPv4-specific, and as extended, IP version agnostic commands. 57 The only FTP mode that works without changes through an IPv6-to-IPv4 58 translator is extended passive. However, many existing FTP servers 59 don't support this mode, and some clients don't ask for it. This 60 document describes server, client and middlebox (if any) behavior 61 that minimizes this problem. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 2. Notational Conventions . . . . . . . . . . . . . . . . . . . . 4 67 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 4. Server requirements . . . . . . . . . . . . . . . . . . . . . 4 69 5. Client requirements . . . . . . . . . . . . . . . . . . . . . 5 70 6. ALG functionality . . . . . . . . . . . . . . . . . . . . . . 6 71 6.1. Control channel translation . . . . . . . . . . . . . . . 6 72 6.2. EPSV to PASV translation . . . . . . . . . . . . . . . . . 7 73 6.3. EPRT to PORT translation . . . . . . . . . . . . . . . . . 8 74 6.3.1. Stateless EPRT translation . . . . . . . . . . . . . . 8 75 6.3.2. Stateful EPRT translation . . . . . . . . . . . . . . 9 76 6.4. Default port 20 translation . . . . . . . . . . . . . . . 9 77 6.5. Both PORT and PASV . . . . . . . . . . . . . . . . . . . . 10 78 6.6. Timeouts . . . . . . . . . . . . . . . . . . . . . . . . . 10 79 7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 10 80 8. Security considerations . . . . . . . . . . . . . . . . . . . 10 81 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 82 9.1. Normative References . . . . . . . . . . . . . . . . . . . 11 83 9.2. Informative References . . . . . . . . . . . . . . . . . . 11 84 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 11 85 Appendix B. Document and discussion information . . . . . . . . . 12 86 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 88 1. Introduction 90 [RFC0959] specifies two modes of operation for FTP: active mode, in 91 which the server connects back to the client, usually to a client- 92 provided port number, and passive mode, where the server opens a port 93 for the client to connect to. Without additional action, active mode 94 with a client-supplied port doesn't work through NATs or firewalls. 95 And in both cases, an IPv4 address is specified, making both the 96 original passive mode and the original active mode incompatible with 97 IPv6. These issues were solved in [RFC2428], which introduces the 98 EPSV (extended passive) mode that only specifies a port number and 99 the EPRT (extended port) command which allows the client to supply an 100 IPv6 address (and a port) to the server. 102 A survey done in April of 2009 of 25 randomly picked and/or well- 103 known FTP sites reachable over IPv4 showed that only 12 of them 104 supported EPSV over IPv4. Additionally, only 2 of those 12 indicated 105 that they supported EPSV in response to the FEAT command ([RFC2389]) 106 that asks the server to list its supported features. One supported 107 EPSV but not FEAT. In 5 cases, issuing the EPSV command to the 108 server led to a significant delay, in 3 cases followed by a control 109 channel reset. It appears that in these cases, the server did 110 support EPSV but a middlebox didn't. All 25 servers were able to 111 successfully complete a transfer in PASV traditional passive mode as 112 required by [RFC1123]. More tests showed that the use of an address 113 family argument with the EPSV command is widely mis- or unimplemented 114 in servers. The additional tests with more servers showed that 115 approximately 65% of FTP servers support EPSV successfully and around 116 96% support PASV successfully. Clients weren't extensively tested, 117 but previous experience from the author suggests that most clients 118 support PASV, with the notable exception of the command line client 119 included with Windows, which only supports active mode. It uses the 120 original PORT command when running over IPv4 and EPRT when running 121 over IPv6. 123 Based on the tests, this document updates [RFC0959] and [RFC2428] in 124 order to disallow certain unusual modes of operation that are 125 incompatible with IPv6-to-IPv4 translation as well as requiring the 126 EPSV capability from all servers. All IPv6 FTP clients are required 127 to implement EPSV. Further, it is recommended that IPv6 clients 128 retry with PASV when EPSV fails under the assumption that they are 129 communicating through an IPv6-to-IPv4 translator. 131 Additionally, there are guidelines for operators choosing to 132 implement an application layer gateway functionality to provide 133 connectivity between unupdated servers and/or clients. It is not 134 required to implement an ALG to conform to this specification. 135 Clients that want to engage in more complex behavior, such as server- 136 to-server transfers, may make an FTP ALG go into transparent mode by 137 issuing an AUTH command. 139 The requirements and recommendations in this document apply to all 140 forms of IPv6-to-IPv4 translation, including stateless translation 141 such as [RFC2765] and stateful translation such as 142 [I-D.bagnulo-behave-nat64]. 144 The FTP protocol allows for complex interactions, such as the 145 situation where a client connects to two servers and directs the 146 servers to exchange data between them. These types of interactions 147 are out of scope for this document. 149 2. Notational Conventions 151 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 152 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 153 document are to be interpreted as described in [RFC2119]. 155 3. Terminology 157 Within the context of this document, the words "client" and "server" 158 refer to FTP client and server implementations, respectively. An FTP 159 server is understood to be an implementation of the FTP protocol 160 running on a server, waiting for clients to connect and issue 161 commands and start data transfers. Clients are pieces of software 162 designed to interact with servers using the FTP protocol, and store 163 (upload) or retrieve (download) files to/from one or more servers, 164 either interactively under control of a user, or as an unattended 165 background process. Most operating systems provide a web browser 166 that implements a basic FTP client, as well as a command line client. 167 Third-party FTP clients are also widely available. 169 Other terminology is derived from the documents listed in the 170 reference section. 172 4. Server requirements 174 All FTP servers MUST support EPSV mode. Further, if a server allows 175 configuration of any kind, it MUST also be configurable to respond 176 with a 502 (command not implemented) error to EPSV and EPRT commands, 177 even though the server is capable of EPSV and/or EPRT. This way, FTP 178 servers residing behind firewalls or other middleboxes that break 179 EPSV or EPRT functionality can be made to trigger clients to fall 180 back to PASV or PORT immediately rather than potentially suffering a 181 timeout. 183 All FTP servers MUST only use the local address used for the control 184 channel session in PASV responses. This allows an ALG to translate 185 the response to the PASV command to an EPSV response without loss of 186 information. Note that according to tests performed by Dan Wing, 187 this requirement is already met in practice. 189 All FTP servers that support the FEAT command (which is highly 190 RECOMMENDED for all servers) MUST indicate support for EPSV and/or 191 EPRT when available in response to the FEAT command and MUST NOT list 192 EPSV and/or EPRT in response to the FEAT command when EPSV and/or 193 EPRT is administratively disabled as outlined above. 195 5. Client requirements 197 All FTP clients MUST support EPSV when communicating over IPv6. 199 It is highly RECOMMENDED that FTP clients react by retrying with PASV 200 or EPRT when the EPSV command fails, either because of an error 201 response by the server (40x, 42x, 50x and 52x responses), because the 202 data connection couldn't be created or because the control channel 203 session was terminated. In the latter two cases, a client MAY cache 204 the name or address of the FTP server and issue PASV rather than EPSV 205 in future sessions. In that case, the cache entry SHOULD be cleared 206 if older than 7 days and the server indicates EPSV support in its 207 FEAT response where it previously did not indicate EPSV support in 208 its FEAT response. There is always a risk that an error was the 209 result of a condition unrelated to IPv6-to-IPv4 translation. 210 However, retrying with a PASV request has little potential for harm, 211 so unless the error is clearly unrelated, retrying with PASV is the 212 appropriate reaction. 214 When an FTP client is communicating over IPv6 and it is unable to use 215 the EPSV (and possibly EPRT) command successfully, it SHOULD retry 216 with PASV. However, the server will respond to the PASV command with 217 an IPv4 address that the client must use to connect to for the data 218 connection. Even if the client has IPv4 reachability, it SHOULD 219 ignore the server-supplied address and set up a data connection 220 towards the IPv6 address of the server that is used for the control 221 channel session. However, the port number used for the data 222 connection is taken from the 227 response to the PASV command. 224 Clients MUST NOT use any arguments with the EPSV command; many IPv4 225 FTP servers react adversely to "EPSV 1". Clients SHOULD assume that 226 servers are unaware of the IP version used by clients. This may be 227 the result from a server implementation that uses the updated IPv6 228 socket API with IPv4-mapped addresses, or because the server resides 229 behind an IPv6-to-IPv4 translator. 231 6. ALG functionality 233 The author recognizes that FTP application layer gateways for 234 compatibility with IPv6-to-IPv4 translators is rejected by many 235 within the IETF community. As such, it is RECOMMENDED to update FTP 236 clients and servers as required for IPv6-to-IPv4 translation support 237 where possible, to allow proper operation of the FTP protocol without 238 the need for ALGs. 240 On the other hand, network operators often have little influence over 241 the FTP clients their customers run, let alone the FTP servers used 242 throughout the Internet. For those operators, deploying an ALG may 243 be the only way to provide a satisfactory customer experience. So, 244 even though not the preferred solution, this document describes the 245 functionality of such an ALG in order to promote consistent behavior 246 between ALGs in an effort to minimize their harmful effects. 247 However, the situation with regard to FTP server and -clients, 248 especially in IPv6-heavy deployments, may change fast, so within 249 relatively little time it may become feasible to stop running an ALG. 250 Operators are encouraged to keep revisiting the issue. 252 Note that the translation of EPSV through all translators and EPRT 253 through a stateless translator is relatively simple and translation 254 of EPRT through a stateful translator relatively difficult. As such, 255 an ALG used with a stateful translator MAY choose to support only 256 EPSV. However, an ALG used with a stateless translator SHOULD also 257 support EPRT. 259 6.1. Control channel translation 261 The IPv6-to-IPv4 FTP ALG intercepts all TCP sessions towards IPv4 262 port 21 destinations. The FTP ALG implements the Telnet protocol 263 ([RFC0854]) used for control channel interactions to the degree 264 necessary to interpret commands and responses and re-issue those 265 commands and responses, modifying them as outlined below. Option 266 negotiation attempts by either the client or the server, except for 267 those allowed by [RFC1123], SHOULD be rejected by the FTP ALG without 268 relaying those attempts. This avoids the situation where the client 269 and the server negotiate options unknown to the FTP ALG. 271 There are two ways to implement the control channel ALG: 273 1. The ALG terminates the IPv6 TCP session, sets up a new IPv4 TCP 274 session towards the IPv4 FTP server, and relays commands and 275 responses back and forth between the two sessions. 277 2. Packets that are part of the control channel are translated 278 individually. 280 In the second case, an implementation must have the ability to track 281 and update TCP sequence numbers when translating packets and break up 282 packets into smaller packets after translation, as the control 283 channel translation may modify the length of the payload portion of 284 the packets in question. Also, FTP commands/responses or Telnet 285 negotiations may straddle packet boundaries, so in order to be able 286 to perform the ALG function, it may be necessary to reconstitute 287 Telnet negotiations and FTP commands and responses from multiple 288 packets. 290 If the client issues the AUTH command the client is attempting to 291 negotiate [RFC2228] security mechanisms which are likely to be 292 incompatible with the FTP ALG function. In this situation, the FTP 293 ALG MUST switch to transparently forwarding all data on the control 294 channel in both directions until the end of the control channel 295 session. This requirement applies regardless of the response from 296 the server. I.e., it is the fact that the client attempts the AUTH 297 negotiation that requires the ALG to become transparent, not whether 298 or not the attempt is successful. 300 There have been FTP ALGs for the purpose of making active FTP work 301 through IPv4 NATs for a long time. Another type of ALG would be one 302 that imposes restrictions required by security policies. Multiple 303 ALGs can be implemented as a single entity. Should such a multi- 304 purpose ALG forbid the use of the AUTH command for policy reasons, 305 the side effect of making the ALG stop performing the translations 306 described here, as well as other possible interventions related to 307 IPv6-to-IPv4 translation, MUST be retained even if the ALG responds 308 to the AUTH command with an error and doesn't propagate the command 309 to the server. (Implementers are further advised that IPv6 hosts 310 using an IPv6-to-IPv4 translator will normally have the ability to 311 execute FTP over IPv6 without interference from the ALG.) 313 6.2. EPSV to PASV translation 315 Although many IPv4 FTP servers support the EPSV command, some servers 316 react adversely to this command, and there is no reliable way to 317 detect in advance that this will happen. As such, an FTP ALG MAY 318 translate all occurrences of the EPSV command issued by the client to 319 the PASV command, and reformat a 227 response as a corresponding 229 320 response. 322 For instance, if the client issues EPSV (or EPSV 2 to indicate IPv6 323 as the network protocol), this is translated to the PASV command. If 324 the server with address 192.0.2.31 then responds with: 326 227 Entering Passive Mode (192,0,2,31,237,19) 328 The FTP ALG reformats this as: 330 229 Entering Extended Passive Mode (|||60691|) 332 If the server's 227 response contains an IPv4 address that doesn't 333 match the destination of the control channel, the FTP ALG SHOULD send 334 the following response to the client: 336 425 Can't open data connection. 338 It is important that the response is in the 4xx range to indicate a 339 temporary condition. 341 If the client issues an EPSV command with a numeric argument other 342 than 2, the ALG MUST NOT pass the command on to the server, but 343 rather respond with a 522 error. 345 If the client issues EPSV ALL, the FTP ALG MUST NOT pass this command 346 to the server, but respond with: 348 202 Command not implemented. 350 This avoids the situation where an FTP server may react adversely to 351 receiving a PASV command after the client indicated that it will only 352 use EPSV during this session. 354 6.3. EPRT to PORT translation 356 Should the IPv6 client issue an EPRT command, the FTP ALG MAY 357 translate this EPRT command to a PORT command. The translation is 358 different depending on whether the translator is a stateless one-to- 359 one translator or a stateful one-to-many translator. 361 6.3.1. Stateless EPRT translation 363 If the address specified in the EPRT command is the client's IPv6 364 address, then the FTP ALG reformats the EPRT command into a PORT 365 command with the IPv4 address that maps to the client's IPv6 address. 366 The port number MUST be preserved for compatibility with stateless 367 translators. 369 If the address specified in the EPRT command is not the client's IPv4 370 address, the ALG's response is undefined. It may pass along the 371 command unchanged, respond with an error, or attempt to perform an 372 appropriate translation. 374 6.3.2. Stateful EPRT translation 376 If the address in the EPRT command is the IPv6 address of the control 377 channel client's address, the stateful translator selects an unused 378 port number in combination with the IPv4 address used for the control 379 channel towards the FTP server, and sets up a mapping from that 380 transport address to the one specified by the client in the EPRT 381 command. The PORT command with the IPv4 address and port used on the 382 IPv4 side of the mapping is only issued towards the server once the 383 mapping is created. Initially, the mapping is such that either any 384 transport address or the FTP server's IPv4 address with any port 385 number is accepted as a source, but once the three-way handshake is 386 complete, the mapping is narrowed to only match the negotiated TCP 387 session. 389 If the address in the EPRT command is not the client's IPv6 address, 390 the ALG's response is undefined. 392 6.4. Default port 20 translation 394 If the client doesn't issue an EPSV/PASV or EPRT/PORT command, it is 395 invoking the default active FTP behavior where the server sets up a 396 TCP session towards the client. In this situation, the source port 397 number is the default FTP data port (port 20) and the destination 398 port is the port the client uses as the source port in the control 399 channel session. 401 In the case of a stateless translator, this doesn't pose any 402 problems. In the case of a stateful translator, the translator 403 SHOULD accept incoming connection requests from the server on the 404 IPv4 side if the transport addresses match that of an existing FTP 405 control channel session, with the exception that the control channel 406 session uses port 21 and the new session port 20. In this case, a 407 mapping is set up towards the same transport address on the IPv6 side 408 that is used for the matching FTP control channel session. 410 So for instance, the client is 2001:db8:31::6 and the server is 411 192.0.2.4. The translator has prefix 2001:db8:ffff:fffff::/96 as its 412 translator prefix and 10.0.0.1 as its IPv4 address. On the IPv6 413 side, the transport addresses for an FTP control channel session 414 could then be 2001:db8:31::6,49152 to 2001:db8:ffff:ffff::c000:204,21 415 on the IPv6 side and 10.0.0.1,60000 to 192.0.2.4,21 on the IPv4 side. 416 If then the FTP server initiates a session from 192.0.2.4,20 to 417 10.0.0.1,60000, the translator sets up a mapping from those addresses 418 to source 2001:db8:ffff:ffff::c000:204,20 destination 2001:db8:31:: 420 6,49152. 422 If there is no (unambiguous) match for an existing data channel 423 session when an incoming session request on port 20 arrives, the 424 connection is refused with a TCP RST. 426 6.5. Both PORT and PASV 428 [RFC0959] allows a client to issue both PORT and PASV to use non- 429 default ports on both sides of the connection. However, this is 430 incompatible with the notion that with PASV the data connection is 431 made from the client to the server, while PORT reaffirms the default 432 behavior where the server connects to the client. As such, the 433 behavior of an ALG is undefined when a client issues both PASV and 434 PORT. 436 6.6. Timeouts 438 Wherever possible, control channels SHOULD NOT time out while there 439 is an active data channel. A timeout of at least 30 seconds is 440 recommended for mappings created by the FTP ALG that are waiting for 441 initial packets. 443 Whenever a command from the client isn't propagated to the server, 444 the FTP ALG instead issues a NOOP command in order to keep the 445 keepalive state between the client and the server synchronized. The 446 response to the NOOP command is not sent back to the client. 448 7. IANA considerations 450 None. 452 8. Security considerations 454 In the majority of cases, FTP is used without further security 455 mechanisms. This allows a passive attacker to obtain the login 456 credentials, and an attacker that can modify packets to change the 457 data transferred. However, FTP can be used with TLS in order to 458 solve these issues. IPv6-to-IPv4 translation and the FTP ALG don't 459 impact the security issues in the former case nor the use of TLS in 460 the latter case. However, if FTP is used with TLS or another 461 authentication mechanism, the ALG function is not performed so only 462 passive transfers from a server that implements EPSV or a client that 463 supports PASV will succeed. 465 9. References 467 9.1. Normative References 469 [RFC0854] Postel, J. and J. Reynolds, "Telnet Protocol 470 Specification", STD 8, RFC 854, May 1983. 472 [RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol", 473 STD 9, RFC 959, October 1985. 475 [RFC1123] Braden, R., "Requirements for Internet Hosts - Application 476 and Support", STD 3, RFC 1123, October 1989. 478 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 479 Requirement Levels", BCP 14, RFC 2119, March 1997. 481 [RFC2389] Hethmon, P. and R. Elz, "Feature negotiation mechanism for 482 the File Transfer Protocol", RFC 2389, August 1998. 484 [RFC2228] Horowitz, M., "FTP Security Extensions", RFC 2228, 485 October 1997. 487 [RFC2428] Allman, M., Ostermann, S., and C. Metz, "FTP Extensions 488 for IPv6 and NATs", RFC 2428, September 1998. 490 9.2. Informative References 492 [RFC2765] Nordmark, E., "Stateless IP/ICMP Translation Algorithm 493 (SIIT)", RFC 2765, February 2000. 495 [I-D.bagnulo-behave-nat64] 496 Bagnulo, M., Matthews, P., and I. Beijnum, "NAT64: Network 497 Address and Protocol Translation from IPv6 Clients to IPv4 498 Servers", draft-bagnulo-behave-nat64-03 (work in 499 progress), March 2009. 501 [I-D.liu-behave-ftp64] 502 Liu, D. and Z. Cao, "IPv6 IPv4 translation FTP 503 considerations", draft-liu-behave-ftp64-03 (work in 504 progress), August 2009. 506 Appendix A. Acknowledgements 508 Kentaro Ebisawa, Remi Denis-Courmont, Mayuresh Bakshi, Sarat 509 Kamisetty, Reinaldo Penno, Alun Jones, Dave Thaler, Mohammed 510 Boucadair, Mikael Abrahamsson and Dapeng Liu contributed ideas and 511 comments. Dan Wing ran experiments with a large number of FTP 512 servers that were very illuminating; many of the choices underlying 513 this document are based on his results. Versions -05 and -06 of this 514 document adopts several important design decisions from 515 [I-D.liu-behave-ftp64]. 517 Iljitsch van Beijnum is partly funded by Trilogy, a research project 518 supported by the European Commission under its Seventh Framework 519 Program. 521 Appendix B. Document and discussion information 523 The latest version of this document will always be available at 524 http://www.muada.com/drafts/. Please direct questions and comments 525 to the BEHAVE or apps area mailinglists or directly to the author. 527 Author's Address 529 Iljitsch van Beijnum 530 IMDEA Networks 531 Avda. del Mar Mediterraneo, 22 532 Leganes, Madrid 28918 533 Spain 535 Email: iljitsch@muada.com