idnits 2.17.1 draft-ietf-shim6-applicability-00.txt: 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 3978, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 229. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 206. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 213. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 219. ** 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. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. 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 10, 2005) is 6865 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) -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-shim6-arch' Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Abley 3 Internet-Draft ISC 4 Expires: January 11, 2006 July 10, 2005 6 Shim6 Applicability Statement 7 draft-ietf-shim6-applicability-00 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of 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 January 11, 2006. 34 Copyright Notice 36 Copyright (C) The Internet Society (2005). 38 Abstract 40 This document discusses the applicability of the Shim6 IPv6 protocol 41 element and associated support protocols to provide site multihoming 42 capabilities in IPv6. 44 Note on Shim6 Maturity 46 Shim6 is a work in progress, and does not currently meet the maturity 47 requirements for advancement to Proposed Standard. 49 A summary of the maturity of the various technical specifications 50 that accompany this document can be found in Section 6. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Architectural Overview . . . . . . . . . . . . . . . . . . . . 3 56 3. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 3 57 4. Implementations . . . . . . . . . . . . . . . . . . . . . . . 3 58 5. Operational Experience . . . . . . . . . . . . . . . . . . . . 4 59 6. Maturity Assessment . . . . . . . . . . . . . . . . . . . . . 4 60 7. Security Considerations . . . . . . . . . . . . . . . . . . . 4 61 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 62 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 4 63 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 10.1 Normative References . . . . . . . . . . . . . . . . . . . 4 65 10.2 Informative References . . . . . . . . . . . . . . . . . . 4 66 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 5 67 A. Change History . . . . . . . . . . . . . . . . . . . . . . . . 5 68 Intellectual Property and Copyright Statements . . . . . . . . 6 70 1. Introduction 72 Site multi-homing is an arrangement by which a site may use multiple 73 paths to the rest of the Internet, to provide better reliability for 74 traffic passing in and out of the site than would be possible with a 75 single path. Some of the motivations for operators to multi-home 76 their network are described in [RFC3582]. 78 In IPv4, site multi-homing is achieved by introducing the additional 79 state required to allow session resilience over re-homing events to 80 the global Internet routing system (sometimes referred to as the 81 Default-Free Zone, or DFZ) [I-D.ietf-multi6-v4-multihoming]. There 82 is concern that this approach will not scale [RFC3221]. 84 In IPv6, site multi-homing in the style of IPv4 is not generally 85 available to end sites due to a strict route aggregation in the DFZ, 86 coupled with Regional Internet Registry (RIR) allocation policies 87 which prohibit the direct assignment of provider-independent (PI) 88 addresses to most end users. Site multi-homing for sites without PI 89 addresses is achieved by assigning multiple addresses to each host, 90 one from each provider. This multi-homing approach provides no 91 transport-layer stability across re-homing events. 93 Shim6 introduces transport-layer mobility across re-homing events 94 using a layer-3 shim approach. State information relating to the 95 multi-homing of two endpoints exchanging unicast traffic is retained 96 on the endpoints themselves, rather than in the network. 97 Communications between shim6-capable hosts and shim6-incapable hosts 98 proceed as normal, but without the benefit of transport-layer 99 stability. The Shim6 approach is thought to have better scaling 100 properties than the IPv4 approach, at the expense of somewhat reduced 101 operational capability. 103 2. Architectural Overview 105 A general architectural overview of Shim6 will be included here. In 106 the absense of useful text in this section, readers may wish to refer 107 to [I-D.ietf-shim6-arch]. 109 3. Applicability 111 A list of shim6 technical specifications will go here, each with a 112 requirements level, per [RFC2026]. 114 4. Implementations 116 There is no known implementation of Shim6. 118 5. Operational Experience 120 There is no known operational experience of Shim6. 122 6. Maturity Assessment 124 Shim6 is not sufficiently mature at the time of writing to be 125 advanced to Proposed Standard [RFC2026]. The following is a list of 126 possible work remaining before such advancement might be sought: 128 o The Shim6 technical specifications enumerated in this document are 129 not yet stable. 130 o The Shim6 technical specifications have yet to resolve all known 131 design choices. 132 o The extent to which the Shim6 architecture is well-understood has 133 yet to be thoroughly gauged. 134 o There is no Management Information Base (MIB) available for Shim6. 135 o There is neither implementation nor operational experience of 136 Shim6. 137 o The Shim6 architecture has known technical ommissions. 139 7. Security Considerations 141 Security considerations go here. 143 8. IANA Considerations 145 IANA considerations go here. 147 9. Acknowledgements 149 This work was supported by the US National Science Foundation 150 (research grant SCI-0427144) and DNS-OARC. 152 10. References 154 10.1 Normative References 156 [I-D.ietf-shim6-arch] 157 Huston, G., "Architectural Commentary on Site Multi-homing 158 using a Level 3 Shim", draft-ietf-shim6-arch-00 (work in 159 progress), July 2005. 161 10.2 Informative References 163 [I-D.ietf-multi6-v4-multihoming] 164 Abley, J., Black, B., and V. Gill, "IPv4 Multihoming 165 Practices and Limitations", 166 draft-ietf-multi6-v4-multihoming-03 (work in progress), 167 January 2005. 169 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 170 3", BCP 9, RFC 2026, October 1996. 172 [RFC3221] Huston, G., "Commentary on Inter-Domain Routing in the 173 Internet", RFC 3221, December 2001. 175 [RFC3582] Abley, J., Black, B., and V. Gill, "Goals for IPv6 Site- 176 Multihoming Architectures", RFC 3582, August 2003. 178 Author's Address 180 Joe Abley 181 Internet Systems Consortium, Inc. 182 950 Charter Street 183 Redwood City, CA 94063 184 US 186 Phone: +1 650 423 1317 187 Email: jabley@isc.org 189 Appendix A. Change History 191 This section should be removed prior to publication. 193 draft-ietf-shim6-applicability-00: First draft, largely incomplete, 194 submitted to facilitate comments on general structure and 195 approach. 197 Intellectual Property Statement 199 The IETF takes no position regarding the validity or scope of any 200 Intellectual Property Rights or other rights that might be claimed to 201 pertain to the implementation or use of the technology described in 202 this document or the extent to which any license under such rights 203 might or might not be available; nor does it represent that it has 204 made any independent effort to identify any such rights. Information 205 on the procedures with respect to rights in RFC documents can be 206 found in BCP 78 and BCP 79. 208 Copies of IPR disclosures made to the IETF Secretariat and any 209 assurances of licenses to be made available, or the result of an 210 attempt made to obtain a general license or permission for the use of 211 such proprietary rights by implementers or users of this 212 specification can be obtained from the IETF on-line IPR repository at 213 http://www.ietf.org/ipr. 215 The IETF invites any interested party to bring to its attention any 216 copyrights, patents or patent applications, or other proprietary 217 rights that may cover technology that may be required to implement 218 this standard. Please address the information to the IETF at 219 ietf-ipr@ietf.org. 221 Disclaimer of Validity 223 This document and the information contained herein are provided on an 224 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 225 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 226 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 227 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 228 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 229 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 231 Copyright Statement 233 Copyright (C) The Internet Society (2005). This document is subject 234 to the rights, licenses and restrictions contained in BCP 78, and 235 except as set forth therein, the authors retain all their rights. 237 Acknowledgment 239 Funding for the RFC Editor function is currently provided by the 240 Internet Society.