idnits 2.17.1 draft-bagnulo-savi-analysis-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 3 instances of too long lines in the document, the longest one being 4 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 348: '...ddress Detection MUST be performed on ...' RFC 2119 keyword, line 505: '... client MUST initiate a Confirm/R...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 8, 2010) is 5156 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC4862' is defined on line 603, but no explicit reference was found in the text == Unused Reference: 'RFC1958' is defined on line 606, but no explicit reference was found in the text Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Bagnulo 3 Internet-Draft UC3M 4 Intended status: Informational J. Halpern 5 Expires: September 9, 2010 Ericsson 6 March 8, 2010 8 Analysis of data-triggered binding creation in SAVI 9 draft-bagnulo-savi-analysis-02 11 Abstract 13 The goal of this document is to serve as input to the design of the 14 Source Address Validation architecture being defined in the SAVI WG. 15 In particular, it analyses the different ways to handle data packets 16 for which no binding exists, and the impact of the different 17 approaches in the overall performance of the network. 19 Status of this Memo 21 This Internet-Draft is submitted to IETF in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 This Internet-Draft will expire on September 9, 2010. 42 Copyright Notice 44 Copyright (c) 2010 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. The Neighbour Discovery case . . . . . . . . . . . . . . . . . 3 61 2.1. Arguments against option 1: treat packets as non 62 compliant packets . . . . . . . . . . . . . . . . . . . . 4 63 2.1.1. Lack of binding state due to packet loss . . . . . . . 4 64 2.1.2. Lack of binding state due to a change in the 65 topology . . . . . . . . . . . . . . . . . . . . . . . 7 66 2.1.3. Lack of binding state due to state loss . . . . . . . 7 67 2.2. Arguments against option 2: trigger the process of 68 binding creation . . . . . . . . . . . . . . . . . . . . . 10 69 3. The DHCP case . . . . . . . . . . . . . . . . . . . . . . . . 11 70 3.1. Potential issues with an approach that treats packets 71 as non compliant packets . . . . . . . . . . . . . . . . . 11 72 4. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 73 5. Informative References . . . . . . . . . . . . . . . . . . . . 14 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 76 1. Introduction 78 The SAVI WG is chartered to produce a solution for address validation 79 with local scope. The basic idea in SAVI is to include some SAVI 80 devices in the topology that would enforce the proper usage of the 81 source IP addresses contained in the packets. A major constraint in 82 SAVI design is that SAVI must not require any changes to end hosts. 83 This basically implies that the SAVI enforcers need to be able to 84 determine which host is authorized to use which IP address. The 85 proposed approaches for SAVI all concur that the SAVI device should 86 sniff the control packets that are related to address assignment, in 87 particular, DHCP and ND. By sniffing those packets the SAVI device 88 can discover which host is legitimately using which address and 89 create a binding for that address. The existence of a binding in a 90 SAVI device implies that the SAVI device has information of which 91 node is authorized to use the address contained in the binding, and 92 any packet contained that address that is coming from a different 93 point of the topology will be treated as a non-compliant packet (e.g. 94 discarded). One aspect where there is still ongoing debate is how to 95 handle data packets for which there is no binding. The main question 96 here is whether to treat as a compliant packet or a non-compliant 97 one. There are many tradeoffs involved in that design choice. The 98 goal of this note is to explore the tradeoffs and serve as input to 99 the ongoing debate. 101 Disclaimer: Joel has not able to fully review the final version and 102 Marcelo have added some potentially controversial text in the new 103 version, so you know who is to blame. 105 2. The Neighbour Discovery case 107 In the case of Neighbour Discovery (ND), the messages that are used 108 to create bindings in the SAVI device are the Neighbour Solicitation 109 (NSOL) and potentially the Neighbour Advertisement (NADV) that are 110 exchanged during the Duplicate Address Detection (DAD) procedure. 111 Each node that configures an IP address performs the DAD procedure by 112 sending a NSOL for the address it is about to configure in its 113 interface. If no NADV is received, the address is assumed to be 114 unused and it is configured in the interface. In terms of SAVI, we 115 have mentioned that the SAVI device will create a binding when it 116 observes a successful DAD procedure for a given address, binding the 117 address for the DAD procedure was executed to the lower layer anchor 118 used by the node performing the DAD. 120 The question that we need to address is: what does the SAVI device 121 should do with data packets for which is has no binding information 122 i.e. addresses for which the SAVI device has not observed a DAD NSOL 123 message? The possible options are: 124 1. Treat the packet as a non compliant packet (which in most of the 125 cases means to discard it) 126 2. Trigger the process of creating a binding (whatever that is). 127 Eventually, if the binding is successfully created, data packets 128 coming from that lower layer anchor will be compliant and hence 129 forwarded. 131 We will next consider the impact of the above options in the design 132 of a SAVI solution. 134 2.1. Arguments against option 1: treat packets as non compliant packets 136 The main argument against this approach is the overall robustness of 137 the resulting network. The main concern that has been stated is that 138 a network running SAVI that implements this option may end up 139 disconnecting legitimate users from the network, by filtering packets 140 coming from them. The net result would a degraded robustness of the 141 network as w whole, since legitimate users would perceive this as a 142 network failure. There are three different causes that resulted in 143 the lack of state in the binding device for a legitimate address, 144 namely, packet loss, state loss and topology change. We will next 145 perform an analysis for each of them. 147 2.1.1. Lack of binding state due to packet loss 149 The DAD procedure is inherently unreliable. It consists on sending a 150 NSOL packet and if no NADV packet is received back, success is 151 assumed and the host starts using the address. In general, the lack 152 of response is because no other host has that particular address 153 configured in their interface, but it may also be the case that the 154 NSOL packet or the NADV packet has been lost. From the sending host 155 perspective there is no difference and the host assumes that it can 156 use the address. In other words, the default action is to allow the 157 host to obtain network connectivity. 159 It should be noted that the loss of a DAD packet has little impact on 160 the network performance, since address coalition is very rare and the 161 host assumes success in that case. By designing a SAVI solution that 162 would discard packets for which there is no binding, we are 163 diametrically changing the default behavior in this respect, since 164 the default would be that if the DAD packets are lost, then the node 165 is disconnected from the network (as its packets are filtered). What 166 is worse, the node has little clue of what is going wrong, since it 167 has successfully configured an address but it has no connectivity. 168 The net result is that the overall reliability of the network has 169 significantly decreased as the lost of a single packet would imply 170 that a host is disconnected from the network. 172 The only mechanism that the DAD has to improve its reliability is to 173 send multiple NSOL. However, current RFC4862 defines a default value 174 of 1 NSOL message for the DAD procedure, so requiring any higher 175 value would imply manual configuration of all the hosts connected to 176 the SAVI domain. 178 2.1.1.1. Why initial packets may be (frequently) lost 180 The case of LANs 182 Devices connecting to a network may experience periods of packet loss 183 after the link-layer becomes available for two reasons: Invalid 184 Authentication state and incomplete topology assessment. In both 185 cases, physical-layer connection occurs initially and presents a 186 medium where packeted are transmissable, but frame forwarding is not 187 available across the LAN. 189 For the authentication system, devices on a controlled port are 190 forced to complete 802.1X authentication which may take multiple 191 round trips and many milliseconds to complete (see IEEE 802.1X-2004). 192 In this time, initial DHCP, IPv6 Neighbour Discovery, Multicast 193 Listener or Duplicate Address Detection messages may be transmitted. 194 However, it has also been noted that some devices have the ability 195 for the IP stack to not see the port as up until 802.1x has 196 completed. Hence, that issue needs investigation to determine how 197 common it is now. 199 Additionally, any system which requires user input at this stage can 200 extend the authentication time, and thus the outage. This is 201 problematic where hosts relying upon DHCP for address configuration 202 time out. 204 Upon completion of authentication, it is feasible to signal upper 205 layer protocols as to LAN forwarding availability. This is not 206 typical today, so it is necessary to assume that protocols are not 207 aware of the preceding loss period. 209 For environments which do not require authentication, addition of a 210 new link can cause loops where LAN frames are forwarded continually. 211 In order to prevent loops, all LANs today run a spanning-tree 212 protocol, which selectively disables redundant ports. Devices which 213 perform spanning-tree calculations are either traditional Spanning- 214 Tree Protocol (STP) (see IEEE802.1D-1998) or rapidly converging 215 versions of the same (RSTP/MSTP) (see IEEE 802.1D-2004 and IEEE 216 802.1Q-2005). 218 Until a port is determined to be an edge port (RSTP/MSTP), the rapid 219 protocol speaker has identified its position within the spanning-tree 220 (RSTP/MSTP) or completed a Listening phase (STP), its packets are 221 discarded. 223 For ports which are not connected to rapid protocol switches, it 224 takes a minimum three seconds to perform edge port determination (see 225 IEEE 802.1D-2004). Alternatively completion of Listening phase takes 226 15 seconds (see IEEE 802.1D-1998). This means that during this 227 period, the link-layer appears available, but initial packet 228 transmissions into and out of this port will fail. 230 It is possible to pre-assess ports as edge ports using manual 231 configuration of all the involved devices and thus make them 232 immediately transmissible. This is never default behaviour though. 234 The case fixed access networks 236 In fixed access networks such as DSL and Cable the end hosts are 237 usually connected to the access network through a residential gateway 238 (RG). If the host interface is initialized prior to the residential 239 gateway getting authenticated and connected to the access network, 240 the access network is not aware of the DAD packets that the host sent 241 out. As an example, in DSL networks the Access Node(DSLAM) that 242 needs to create and maintain binding state will never see the DAD 243 message that is required to create such state. 245 2.1.1.1.1. Special sub-case:SAVI device rate-limiting packets 247 A particular sub-case is the one where the SAVI device itself "drops" 248 ND packets. In order to protect itself against DoS attacks and 249 flash-crowds, the SAVI device will have to rate-limit the processing 250 of packets triggering the state creation process (which require 251 processing from the SAVI device). This implies that the SAVI device 252 may not process all the ND packets in case it is under heavy 253 conditions. The result is that the SAVI device will fail to create a 254 binding for a given DAD NSOL packet, which implies that the data 255 packets coming from the host that sent the DAD NSOL packet will be 256 filtered if this approach is adopted. The problem is that the host 257 will assume that the DAD procedure was successful and will not 258 perform the DAD procedure again which in turn will imply that the 259 host will be disconnected from the network. While it is true that 260 the SAVI device will also have to rate limit the processing of the 261 data packets, the host will keep on sending data packets, so it is 262 possible to recover from the alternative approach where data packets 263 trigger the binding creation procedure. 265 2.1.2. Lack of binding state due to a change in the topology 267 In the case SAVI is being deployed in a switched Ethernet network, 268 topology changes may result in a SAVI device receiving packets from a 269 legitimate user for which the SAVI device does not have a binding 270 for. Consider the following example: 272 +------+ +--------+ +---------------+ 273 |SAVI I|-------------|SWITCH I|-------|rest of the net| 274 +------+ +--------+ +---------------+ 275 | | 276 | +--------+ 277 | | SAVI II| 278 | +--------+ 279 | +----------+ | 280 +---|SWITCH II |-----+ 281 +----------+ 282 | 283 +-----+ 284 | Host| 285 +-----+ 287 Suppose that after bootstrapping all the elements are working 288 properly and the spanning tree is rooted in the router and it 289 includes one branch that goes SWITCH I-SAVI I- SWITCH II and another 290 branch that goes SWITCH I-SAVI II. 292 Suppose that the Host boots at this moment and sends the DAD NSOL. 293 The message is propagated through the spanning tree and it received 294 by SAVI I but not by SAVI II. SAVI I creates the binding. 296 Suppose that SAVI I fails and the spanning tree reconverges to SWITCH 297 I- SAVI II- SWITCH II. Now data packets coming from the Host will be 298 coursed through SAVI II which does not have binding state and will 299 drop the packets. 301 2.1.3. Lack of binding state due to state loss 303 The other reason why a SAVI device may not have state for a 304 legitimate address is simply because it lost it. State can be lost 305 due to a reboot of the SAVI device or other reasons such as memory 306 corruption. So, the situation would be as follows: The host performs 307 the DAD procedure and the SAVI device creates a binding for the 308 host's address. The host successfully communicate for a while. The 309 SAVI device reboots and lost the binding state. The packets coming 310 from the host are now discarded as there is no binding state for that 311 address. It should be noted that in this case, the host has been 312 able to use the address successfully for a certain period of time. 314 Architecturally, the degradation of the network robustness in this 315 case can be easily explained by observing that this approach to SAVI 316 implementation breaks the fate-sharing principle. RFC 1958 reads: 317 An end-to-end protocol design should not rely on the maintenance 318 of state (i.e. information about the state of the end-to-end 319 communication) inside the network. Such state should be 320 maintained only in the endpoints, in such a way that the state can 321 only be destroyed when the endpoint itself breaks (known as fate- 322 sharing). 323 By binding the fate of the host's connectivity to the state in the 324 SAVI device, we are breaking this principle and the result is 325 degraded network resilience. 327 Moving on to more practical matters, we can dig deeper into the 328 actual behaviour by considering two scenarios, namely, the case where 329 the host is directly connected to the SAVI device and the case where 330 there is an intermediate device between the two. 332 2.1.3.1. The case of a host directly connected to the SAVI device 334 The considered scenario is depicted in the following picture: 336 +------+ +-----------+ +---------------+ 337 | Host |-------------|SAVI device|-------|rest of the net| 338 +------+ +-----------+ +---------------+ 340 The key distinguishing element of this scenario is that the host is 341 directly connected to the SAVI device. As a result, if the SAVI 342 device reboots, the host will see the carrier disappear and appear 343 again. 345 RFC4862 requires that the DAD procedure is performed when the IP 346 address is assigned to the interface, quoting RFC4862 section 5.4. 347 Duplicate Address Detection: 348 Duplicate Address Detection MUST be performed on all unicast 349 addresses prior to assigning them to an interface, regardless of 350 whether they are obtained through stateless autoconfiguration, 351 DHCPv6, or manual configuration, with the following exceptions:... 353 However, it has been stated that some of the widely used OSes 354 actually do perform DAD each time the link is up, but further data 355 would be required to take this for granted. Assuming that behaviour, 356 that implies that if the lost of state in the SAVI device also 357 results in the link to the host going down, then the host using the 358 tested OSes would redo the DAD procedure allowing the recreation of 359 the binding state in the SAVI device and preserving the connectivity 360 of the host. This would be the case if the SAVI device reboots. It 361 should be noted though, that it is also possible that the binding 362 state is lost for whatever error in the SAVI process and that the 363 SAVI link does not goes down. In this case, the host would not redo 364 the DAD procedure. However, it has been pointed out that it would be 365 possible to require the SAVI process to flap the links of the device 366 it is running, in order to make sure that the links goes down each 367 time the SAVI process restarts and improving the chances the host 368 will redo the DAD procedure when the SAVI process is rebooted. 370 2.1.3.2. The case of a host connected to the SAVI device through one or 371 more legacy devices. 373 The considered scenario is depicted in the following picture: 375 +------+ +-------------+ +-----------+ +---------------+ 376 | Host |------|Legacy device|-------|SAVI device|-------|rest of the net| 377 +------+ +-------------+ +-----------+ +---------------+ 379 The key distinguishing element of this scenario is that the host is 380 not directly connected to the SAVI device. As a result, if the SAVI 381 device reboots, the host will not see any changes. 383 In this case, the host would get get disconnected from the rest of 384 the network since the SAVI device would filter all its packets once 385 the state has gone. As the node will not perform the DAD procedure 386 again, it will remain disconnected until it reboots. 388 As a final comment, it should be noted that it may not be obvious to 389 the network admin which scenario its network is running. Consider 390 the case of a campus network where all the switches in the network 391 are SAVI capable. A small hub connected in the office would turn 392 this into the scenario where the host is not directly connected to 393 the SAVI device. Moreover, consider the case of a host running 394 multiple virtual machines connected through a virtual hub, depending 395 on the implementation of such a virtual hub, may turn a directly 396 connected host scenario to the scenario where the multiple (virtual) 397 hosts are connected through a legacy (virtual) hub. 399 2.1.3.2.1. Enforcing direct connectivty between the SAVI device and the 400 host 402 Some people have argued that enforcing the direct connectivity 403 between the SAVI device and the end host is actually a feature. 404 There are several comments that can be made in this respect: 405 First, it may well be the case in some scenarios this is 406 desirable, but it is certainly not the case in most scenarios. 407 Because of that, the issue of enforcing direct connectivity must 408 be treated as orthogonal to how data packets for which there is no 409 binding are treated, since a general solution must support 410 directly connected nodes and nodes connected through legacy 411 switches. 412 Second, as a matter of fact, the resulting behaviour described 413 above would not actually enforce direct connectivity between the 414 end host and the SAVI device as it would work as long as the SAVI 415 device would not reboot. So, the argument being made is that this 416 approach is not good enough to provide a a robust network service, 417 but it is not bad enough to enforce the direct connectivity of 418 host to the SAVI switch. 419 Third, it should be noted that topology enforcement is not part of 420 the SAVI problem space and that the SAVI problem by itself is hard 421 enough to add additional requirements. 423 2.2. Arguments against option 2: trigger the process of binding 424 creation 426 The main argument against the option of using data packets for which 427 there is no binding to trigger the binding creation process is as 428 follows: 429 It has been stated that some switch architectures would not be 430 able to implement a SAVI solution that triggers complex actions 431 based on data packets. The argument is that some architectures 432 may be able to perform simple actions such as forward or discard, 433 but they wouldn't be able to do more complex actions, such as 434 triggering the binding creation process, that would likely imply 435 sending some packets and creating the binding internally. It has 436 been accepted though, that some switch architectures would be able 437 to trigger the binding creation procedure upon the reception of a 438 data packet. So, if a solution would rely on triggering the 439 binding creation as the result of receiving a data packet, it 440 seems to be the case that some implementations would not be able 441 to comply with the resulting RFC while some other implementations 442 would. 444 Another argument against this option has to do with the added 445 complexity. It is obvious that since this approach is a superset of 446 the previous one it is more complex. In particular, since the SAVI 447 device needs to react upon data packets, it would require more 448 processing power than the alternative approach. (this requires more 449 elaboration) 451 NOTE:Is there any other argument against this option? 453 3. The DHCP case 455 Similar to the ND case, the DHCP based SAVI will create a binding 456 state after observing the message exchange that results in a 457 successful IP address assignment from the DHCP server tot he host. 458 The question is what to do with data packets for which there is no 459 binding state. Similar to the ND case, the options are either to 460 treat it as a non compliant packet (i.e. drop) or to trigger the 461 binding creation procedure. However, at the time of this writing, 462 only the details of a solution that treat these packets as non 463 compliant have been fleshed out and it is not clear how a solution 464 that triggers the binding creation would work. So, in this section, 465 we mostly point out some issues that may require some thought when 466 considering a solution that treats data packets for which there is no 467 binding as non compliant packets and the impact that such solution 468 could have on the overall performance of the network. 470 The DHCP case is different than the ND case, for two main reasons: 471 o The DHCP exchange is reliable and in case of failure the node does 472 not acquire an address (as opposed to the ND case, which is 473 unreliable and that in case of DAD packet getting lost, the host 474 does acquire the address). 475 o Some of the address assignment information is stored in the DHCP 476 server, so in case of failure, there is a central repository to 477 retrieve some of the information. 479 3.1. Potential issues with an approach that treats packets as non 480 compliant packets 482 Since the DHCP exchange is reliable, the arguments based on packet 483 loss do not apply to the DHCP case. We then only need to consider 484 the arguments based on state loss and on topology change. 486 Arguments based on state loss 488 We need to distinguish the two topologies analyzed in the ND case, 489 namely, the case of the host directly connected to the SAVI device 490 and the case of the host connected to a legacy device. 492 In the case the host is directly connected to the SAVI device, the 493 DHCP specification (RFC3315) reads: 495 Whenever a client may have moved to a new link, the prefixes from 496 the addresses assigned to the interfaces on that link may no 497 longer be appropriate for the link to which the client is 498 attached. Examples of times when a client may have moved to a new 499 link include: 500 * The client reboots. 501 * The client is physically connected to a wired connection. 502 * The client returns from sleep mode. 503 * The client using a wireless technology changes access points. 504 In any situation when a client may have moved to a new link, the 505 client MUST initiate a Confirm/Reply message exchange. 507 It is not clear what should a host do when for instance the AP that 508 it is directly connected to reboots. In this case, the access point 509 is still the same, so there is not clear guidance on RFC3315. there 510 are claims that some OSes do redo the Confirm/Reply exchange when the 511 link flaps, but further data would be required to take this for 512 granted. 514 Assuming that behaviour, we could rely on the same trick described 515 earlier, about requiring the SAVI process to flap all the links of 516 the device it is running on, in order to deal with SAVI process 517 failure modes that do not imply a reboot of the whole device. 519 In the case the host is connected to a legacy device, the rebooting 520 of the SAVI device would not result in the host performing a Confirm/ 521 Reply exchange. In this case, it is not clear (to us at least) how 522 the SAVI device could restore the lost SAVI binding state. One 523 option could be to try to retrieve it from the DHCP server. One 524 potential problem with that is that it is not obvious that the DHCP 525 server knows the lower layer anchor information. In addition, that 526 would require a protocol between the SAVI device and the DHCP server. 527 Another possible option would be that the SAVI device forces the host 528 to perform a Confirm/Reply exchange, but since they are not directly 529 connected, it is not obvious how this could be done. 531 It has been argued that this problem can be solved if the binding 532 information is stored in non-volatile memory. Staying away from the 533 implementation aspect of whether this is feasible in the different 534 switch architectures, the problem with non-volatile memory to store 535 dynamic information is that they are, actually non volatile. This 536 may result in the SAVI device filtering based on stalled information. 537 Consider the following case: 539 +------+ +--------+ +---------------+ 540 +------|SAVI I|-------------|SWITCH I|-------|rest of the net| 541 | +------+ +--------+ +---------------+ 542 | | | 543 +---------+ | +--------+ 544 |SWITCHIII| | | SAVI II| 545 +---------+ | +--------+ 546 | | +----------+ | 547 +------+ +---|SWITCH II |-----+ 548 |Host 1| +----------+ 549 +------+ 551 Consider the case where we have SAVI I and SAVI II storing the SAVI 552 state in non volatile memory. Suppose that Host I connects to the 553 network and gets IP address IP1 from the DHCP server. 555 Suppose that now the power of SAVI I goes down and stays down for a 556 few hours. Suppose that Host I leaves the network and Host II 557 attaches to the network in SWITCH II as depicted below. The spanning 558 tree goes SWITCH I-SAVI II-SWITCH II. 560 +------+ +--------+ +---------------+ 561 +------|SAVI I|-------------|SWITCH I|-------|rest of the net| 562 | +------+ +--------+ +---------------+ 563 | | | 564 +---------+ | +--------+ 565 |SWITCHIII| | | SAVI II| 566 +---------+ | +--------+ 567 | +----------+ | 568 +---|SWITCH II |-----+ 569 +----------+ 570 | 571 +-------+ 572 |Host II| 573 +-------+ 575 Suppose that SAVI I boots and now the spanning tree changes and goes 576 SWITCH I- SAVI I- SWITCH II. Now packets of Host II will be 577 forwarded through SAVI I. But Host II has IP1 as IP address, but SAVI 578 I still holds the state referring to Host I through the port through 579 which SWITCH III is connected. The result is that SAVI I will drop 580 the packets coming from Host II. 582 Arguments based on change in the topology 583 the same argument referring to changes in the topology apply to the 584 DHCP case. The result is that changes in the topology may result in 585 the SAVI device filtering packets for legitimate users. 587 4. Acknowledgments 589 Greg Daley and Surech Krishnan provided the text for section entitled 590 "Why initial packets may be (frequently) lost" 592 Alberto Garcia Martinez brought up the issues related to change in 593 the topology and provided the topologies for both the cases of 594 toplogy change as well as the case for non volatile memory. 596 Marcelo Bagnulo is partly funded by Trilogy, a research project 597 supported by the European Commission under its Seventh Framework 598 Program and by the Telefonica Chair at University Carlos III of 599 Madrid.. 601 5. Informative References 603 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 604 Address Autoconfiguration", RFC 4862, September 2007. 606 [RFC1958] Carpenter, B., "Architectural Principles of the Internet", 607 RFC 1958, June 1996. 609 Authors' Addresses 611 Marcelo Bagnulo 612 Universidad Carlos III de Madrid 613 Av. Universidad 30 614 Leganes, Madrid 28911 615 SPAIN 617 Phone: 34 91 6248814 618 Email: marcelo@it.uc3m.es 619 URI: http://www.it.uc3m.es 621 Joel M. Halpern 622 Ericsson 624 Phone: 1 703 371 3043 625 Email: joel.halpern@ericsson.com