idnits 2.17.1 draft-bi-savi-mix-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Unrecognized Status in 'Intended status: Standard Tracks', assuming Proposed Standard (Expected one of 'Standards Track', 'Full Standard', 'Draft Standard', 'Proposed Standard', 'Best Current Practice', 'Informational', 'Experimental', 'Informational', 'Historic'.) == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 8, 2010) is 4911 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) == Unused Reference: 'RFC2119' is defined on line 320, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 SAVI Jun Bi 2 Internet Draft CERNET 3 Intended status: Standard Tracks Guang Yao 4 Expires: May 2011 Tsinghua Univ. 5 Joel M. Halpern 6 Newbridge Networks Inc. 7 Eric Levy-Abegnoli 8 Cisco System 9 November 8, 2010 11 SAVI for Mixed Scenario 12 draft-bi-savi-mix-02.txt 14 Status of this Memo 16 This Internet-Draft is submitted to IETF in full conformance with 17 the provisions of BCP 78 and BCP 79. This document may not be 18 modified, and derivative works of it may not be created, except to 19 publish it as an RFC and to translate it into languages other than 20 English. 22 This document may contain material from IETF Documents or IETF 23 Contributions published or made publicly available before November 24 10, 2008. The person(s) controlling the copyright in some of this 25 material may not have granted the IETF Trust the right to allow 26 modifications of such material outside the IETF Standards Process. 27 Without obtaining an adequate license from the person(s) controlling 28 the copyright in such materials, this document may not be modified 29 outside the IETF Standards Process, and derivative works of it may 30 not be created outside the IETF Standards Process, except to format 31 it for publication as an RFC or to translate it into languages other 32 than English. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF), its areas, and its working groups. Note that 36 other groups may also distribute working documents as Internet- 37 Drafts. 39 Internet-Drafts are draft documents valid for a maximum of six 40 months and may be updated, replaced, or obsoleted by other documents 41 at any time. It is inappropriate to use Internet-Drafts as 42 reference material or to cite them other than as "work in progress." 44 The list of current Internet-Drafts can be accessed at 45 http://www.ietf.org/ietf/1id-abstracts.txt 46 The list of Internet-Draft Shadow Directories can be accessed at 47 http://www.ietf.org/shadow.html 49 This Internet-Draft will expire on May 8, 2011. 51 Copyright Notice 53 Copyright (c) 2010 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (http://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with 61 respect to this document. Code Components extracted from this 62 document must include Simplified BSD License text as described in 63 Section 4.e of the Trust Legal Provisions and are provided without 64 warranty as described in the Simplified BSD License. 66 Abstract 68 This document specifies the procedure a SAVI device resolves conflict 69 from multiple co-existing SAVI solutions. 71 Table of Contents 73 Copyright Notice ............................................... 2 74 1. Introduction ................................................ 3 75 2. Terminology ................................................. 3 76 3. Mixed Scenario .............................................. 3 77 4. Basic SAVI-MixMode Structure................................. 3 78 5. Problem Scope and Statement.................................. 4 79 5.1. Problem Scope .......................................... 4 80 5.2. Collision in Binding Set-up Procedure................... 4 81 5.2.1. Proposed solution.................................. 5 82 5.3. Collision in Binding Removal............................ 7 83 6. Security Considerations...................................... 7 84 7. IANA Considerations ......................................... 7 85 7.1. Normative References.................................... 7 86 7.2. Informative References.................................. 8 87 8. Acknowledgments ............................................. 8 89 1. Introduction 91 SAVI solutions are specified for scenarios allowing only single 92 address assignment method without considering the co-existing of 93 multiple address assignment methods. In practice, for both IPv4 and 94 IPv6 network, generally multiple address assignment methods are 95 allowed. Current SAVI solutions cannot be used directly in such 96 scenarios, because collision between solutions may happen. This 97 document specifies the possible collisions and proposes 98 corresponding mechanism to solve the collisions. 100 2. Terminology 102 Address Assignment Source (AAS): The de facto entity type that 103 assigns address. 105 3. Mixed Scenario 107 Currently, there are actually four SAVI solutions which cover 108 different types of addresses: 110 (1) SAVI-FCFS: SLAAC 112 (2) SAVI-DHCP: stateful DHCP, static DHCP 114 (3) SAVI-SEND: CGA with certificate, CGA without certificate 116 (4) Manually configuration: static address manually configured by 117 administrator on SAVI device statically. Note: address 118 configured by user on host is treated as stateless address. 120 A practical network may enable any combination of address assignment 121 methods, and all the corresponding solutions should be enabled to 122 avoid legitimate packet filtering. If more than one SAVI solution is 123 enabled on SAVI device, the scenario is named as mix scenario in 124 this document. 126 4. Basic SAVI-MixMode Structure 128 Existing SAVI solutions are individual mechanism without considering 129 inter-cooperation. To keep the independence and completeness of each 130 solution, a SAVI solution is treated as a black box which snoops 131 packet and generates/removes candidate binding, without concerning 132 the inner structure of each solution. 134 Because the binding entry setup by each solution is ALLOW entry, 135 thus a solution will reject any address not bound by it. However, 136 address bound by any solution must be allowed if no collision, thus, 137 binding entry table should be shared by all the solutions. The main 138 work of this document is handling the conflict resulted from 139 solutions sharing the binding table. 141 If bindings on different addresses are set up by different solutions, 142 no collisions can happen. Thus, a guideline here is to separate the 143 address space of each type to avoid any kind of collision. However, 144 if there is overlap between address spaces, bindings on the same 145 address can be set up by different solutions, and collision can 146 happen. 148 5. Problem Scope and Statement 150 5.1. Problem Scope 152 This document is specified for collision between SAVI solutions. The 153 situation that collision happens in a single solution, for example, 154 the same address is bound by the same solution on different binding 155 anchors, is not in the scope of this document. 157 SAVI solutions mainly specify the setup and remove of bindings. 158 Whenever a solution sets up a binding or removes an existing binding, 159 it may violate the state of other solutions. In the mix mode, the 160 SAVI device must decide whether to accept the operation request from 161 each solution or not. 163 5.2. Collision in Binding Set-up Procedure 165 In binding set up, collision happens when: 167 (1) the same address 169 (2) different binding anchors on the SAVI perimeter and 171 (3) different binding solutions. 173 As an instance, after an address is bound on one binding anchor by 174 DHCP solution, the FCFS solution requires to bind the address on 175 another binding anchor. Both bindings are legitimate in 176 corresponding solution; however, only one of the bindings should be 177 allowed. Then the SAVI device must decide whom the address should be 178 bound with. 180 NOTE: because a single SAVI device doesn't have the information of 181 all bound addresses on the perimeter, a collision may not be 182 explicit based only on local bindings. To make the perimeter-scope 183 collision explicit to each SAVI device, which means, a SAVI device 184 must distinguish whether a local binding setup request violate a 185 binding on other devices or not. 187 Following mechanism can be used: 189 (1) SAVI device performs DAD proxy for local manually configured 190 address even if the node with static address is off-link;(Or to 191 manually configure all the SAVI devices is also proposed.) 193 Then the collision that SAVI-FCFS request static address can be 194 handled. 196 (2) Static address must be excluded from DHCP address pool; 198 Then the collision that SAVI-DHCP request static address can be 199 handled. 201 (3) SAVI device performs DAD proxy for local DHCP address. 203 Then the collision that SAVI-FCFS request DHCP address on other 204 SAVI devices can be handled. 206 5.2.1. Proposed solution 208 To make a choice between candidate bindings, a preference level 209 based solution is thought to be efficient from the experience of 210 similar implementations. 212 The essential problem is: 1. The granularity of preference level; 2. 213 The basis of preference level (or at least the default level). 215 The preference level proposed in this document is an AAS (Address 216 Assignment Source) granularity preference level. And preference 217 level is assigned based on the trustworthy of AAS and the sequence 218 of candidate bindings. 220 By now, there are 4 types of AAS: 222 (1) Node itself: SLAAC, CGA without certificate 224 (2) DHCP sever: stateful DHCP address 226 (3) PKI: CGA with certificate, plain address with certificate 228 (4) Administrator: static address, static DHCP address(may not be 229 taken into consideration as no standard document) 231 Combined with binding sequence, there will be 16 scenarios: 233 FORMER LARER PREFERENCE 235 Node Node In the scope of SAVI-SLAAC 237 Node DHCP Switch here: either former or later 239 Node PKI Later 241 Node Admin Later 243 DHCP Node Former 245 DHCP DHCP In the scope of SAVI-DHCP 247 DHCP PKI Later 249 DHCP Admin Later 251 PKI Node Former 253 PKI DHCP Former 255 PKI PKI No definition 257 PKI Admin Later 259 Admin Node Former 261 Admin DHCP Former 263 Admin PKI Former 265 Admin Admin Later(Or not in scope of this document) 267 If ignoring the details, the basic preference level of AAS is simply 268 node