idnits 2.17.1 draft-bi-savi-mix-01.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 : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 1. Introduction' ) ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 6. Security Considerations' ) ** 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.) (A line matching the expected section header was found, but with an unexpected indentation: ' No IANA consideration.' ) ** There are 7 instances of too long lines in the document, the longest one being 41 characters in excess of 72. 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 4917 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 section? 'RFC2119' on line 319 looks like a reference Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). 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-01.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 88 1. Introduction 90 SAVI solutions are specified for scenarios allowing only single 91 address assignment method without considering the co-existing of 92 multiple address assignment methods. In practice, for both IPv4 and 93 IPv6 network, generally multiple address assignment methods are 94 allowed. Current SAVI solutions cannot be used directly in such 95 scenarios, because collision between solutions may happen. This 96 document specifies the possible collisions and proposes 97 corresponding mechanism to solve the collisions. 99 2. Terminology 101 Address Assignment Source (AAS): The de facto entity type that 102 assigns address. 104 3. Mixed Scenario 106 Currently, there are actually four SAVI solutions which cover 107 different types of addresses: 109 (1) SAVI-FCFS: SLAAC 111 (2) SAVI-DHCP: stateful DHCP, static DHCP 113 (3) SAVI-SEND: CGA with certificate, CGA without certificate 115 (4) Manually configuration: static address manually configured by 116 administrator on SAVI device statically. Note: address 117 configured by user on host is treated as stateless address. 119 A practical network may enable any combination of address assignment 120 methods, and all the corresponding solutions should be enabled to 121 avoid legitimate packet filtering. If more than one SAVI solution is 122 enabled on SAVI device, the scenario is named as mix scenario in 123 this document. 125 4. Basic SAVI-MixMode Structure 127 Existing SAVI solutions are individual mechanism without considering 128 inter-cooperation. To keep the independence and completeness of each 129 solution, a SAVI solution is treated as a black box which snoops 130 packet and generates/removes candidate binding, without concerning 131 the inner structure of each solution. 133 Because the binding entry setup by each solution is ALLOW entry, 134 thus a solution will reject any address not bound by it. However, 135 address bound by any solution must be allowed if no collision, thus, 136 binding entry table should be shared by all the solutions. The main 137 work of this document is handling the conflict resulted from 138 solutions sharing the binding table. 140 If bindings on different addresses are set up by different solutions, 141 no collisions can happen. Thus, a guideline here is to separate the 142 address space of each type to avoid any kind of collision. However, 143 if there is overlap between address spaces, bindings on the same 144 address can be set up by different solutions, and collision can 145 happen. 147 5. Problem Scope and Statement 149 5.1. Problem Scope 151 This document is specified for collision between SAVI solutions. The 152 situation that collision happens in a single solution, for example, 153 the same address is bound by the same solution on different binding 154 anchors, is not in the scope of this document. 156 SAVI solutions mainly specify the setup and remove of bindings. 157 Whenever a solution sets up a binding or removes an existing binding, 158 it may violate the state of other solutions. In the mix mode, the 159 SAVI device must decide whether to accept the operation request from 160 each solution or not. 162 5.2. Collision in Binding Set-up Procedure 164 In binding set up, collision happens when: 166 (1) the same address 168 (2) different binding anchors on the SAVI perimeter and 170 (3) different binding solutions. 172 As an instance, after an address is bound on one binding anchor by 173 DHCP solution, the FCFS solution requires to bind the address on 174 another binding anchor. Both bindings are legitimate in 175 corresponding solution; however, only one of the bindings should be 176 allowed. Then the SAVI device must decide whom the address should be 177 bound with. 179 NOTE: because a single SAVI device doesn't have the information of 180 all bound addresses on the perimeter, a collision may not be 181 explicit based only on local bindings. To make the perimeter-scope 182 collision explicit to each SAVI device, which means, a SAVI device 183 must distinguish whether a local binding setup request violate a 184 binding on other devices or not. 186 Following mechanism can be used: 188 (1) SAVI device performs DAD proxy for local manually configured 189 address even if the node with static address is off-link;(Or to 190 manually configure all the SAVI devices is also proposed.) 192 Then the collision that SAVI-FCFS request static address can be 193 handled. 195 (2) Static address must be excluded from DHCP address pool; 197 Then the collision that SAVI-DHCP request static address can be 198 handled. 200 (3) SAVI device performs DAD proxy for local DHCP address. 202 Then the collision that SAVI-FCFS request DHCP address on other 203 SAVI devices can be handled. 205 5.2.1. Proposed solution 207 To make a choice between candidate bindings, a preference level 208 based solution is thought to be efficient from the experience of 209 similar implementations. 211 The essential problem is: 1. The granularity of preference level; 2. 212 The basis of preference level (or at least the default level). 214 The preference level proposed in this document is an AAS (Address 215 Assignment Source) granularity preference level. And preference 216 level is assigned based on the trustworthy of AAS and the sequence 217 of candidate bindings. 219 By now, there are 4 types of AAS: 221 (1) Node itself: SLAAC, CGA without certificate 223 (2) DHCP sever: stateful DHCP address 225 (3) PKI: CGA with certificate, plain address with certificate 227 (4) Administrator: static address, static DHCP address(may not be 228 taken into consideration as no standard document) 230 Combined with binding sequence, there will be 16 scenarios: 232 FORMER LARER PREFERENCE 234 Node Node In the scope of SAVI-SLAAC 236 Node DHCP Switch here: either former or later 238 Node PKI Later 240 Node Admin Later 242 DHCP Node Former 244 DHCP DHCP In the scope of SAVI-DHCP 246 DHCP PKI Later 248 DHCP Admin Later 250 PKI Node Former 252 PKI DHCP Former 254 PKI PKI No definition 256 PKI Admin Later 258 Admin Node Former 260 Admin DHCP Former 262 Admin PKI Former 264 Admin Admin Later(Or not in scope of this document) 266 If ignoring the details, the basic preference level of AAS is simply 267 node