csf课程资源地址收集及CSF格式介绍【I】

教学资源的收集与处理一、常用的教学资源库国家基础教育资源网.cn/河南基础教育资源网人民教育出版社.cn/北师大出版社（基础教育）西师大出版社华东师大出版社（基础教育）大象网中学学科网K12教育资源库二、利用搜索引擎搜索教学资源大海能捞针？互联网是巨大的资源库，而搜索引擎能帮助我们找到想要的资源，前提是准确描述我们需要的是什么。

指令是我们和搜索引擎交流的“语言”。

1、Google平台初阶搜索❖搜索单个关键词示例：查询有关“伸出爱的手”的信息❖搜索结果要求包含两个及两个以上关键字使用空格键分隔两个关键字示例：搜索：教学设计伸出爱的手2、杂项语法❖“site”表示搜索结果局限于某个具体网站或者网站频道示例：在人民教育出版社网站上搜索关于“伸出爱的手”的有关内容搜索：伸出爱的手site:❖在某一类文件中查找信息“filetype:”是Google开发的非常强大实用的一个搜索语法用于定位在某一类文件当中查找信息示例：搜索伸出爱的手的ppt课件。

搜索：伸出爱的手filetype:ppt❖在搜索结果中排除某一项示例：搜索伸出爱的手一课的相关内容，但不包含课件搜索：伸出爱的手-课件三、下载常用软件软件下载网站有很多，但很多网站的下载带有插件及一些欺骗性信息，建议利用360安全卫士中的软件管家来下载、卸载、管理软件。

1、下载软件打开360安全卫士，选择软件管家，按左边的类别及右边的详细介绍选择软件下载2、卸载软件在软件管家中选择软件卸载，然后选择要卸载的软件进行卸载四、百度文库的使用百度文库是百度为网友提供的信息存储空间，是供网友在线分享文档的开放平台。

在这里，用户可以在线阅读和下载包括课件、习题、论文报告、专业资料、各类公文模板以及法律法规、政策文件等多个领域的资料。

1、注册百度，送10点财富2、搜索你想要的内容可以选择类别如：doc、ppt等3、浏览你找的的文档，需要下载可在左下角点“下载”按钮，根据提示扣除相应财富值即可。

多媒体素材创作系列教程国内主要教育资源库简介目前，我国较大规模的教育资源库有：K12智囊教育资源库真源多媒体教育资源库＆平台ChinaSchool 2000 多媒体网络教学资源库科利华“全国中心教育资源库”南海教育资源库洪恩精品课件资源库清华同方公司中国基础教育知识仓库（CFED）……K12智囊教育资源库1.K12网简介K12网是中国中小学教育教学网（http：//）的简称，主要面向中小学学生、教师和家长，提供教育新闻、教师频道、学生频道、家长频道、K12教育论坛、学校与教师免费主页空间、免费电子邮件等大量服务，特色栏目有教学软件交流中心、教案交流中心、试题交流中心、素材交流中心、论文交流中心，是我国基础教育最大的网上教育资源集散地。

2.《K12智囊教育资源库》简介（http://168.160.224.48/jump/ziyuan/）《K12智囊教育资源库》是K12中国中小学教育教学网继成功地推出《K12教育资源库》标准版之后，又投入巨资，组织专家、教授和大批中小学特级、高级教师，联合国内几家最优秀的教育软件公司，共同开发的又一特大型教育资源库。

该资源库主要分为三个版本，包括小学版、初中版和高中版，其中每版各90张光盘。

每版包括十大块：学科素材库、交流课件库、同步教学、学科知识博览、教研论文、教育大观、共享软件、课外百科、通用图片库和通用音效库。

学科素材库包括mpg、avi视频动画、jpg学科图片、wav配音、flash课件片断等。

初中版和高中版均包括语文、数学、英语、物理、化学、历史、地理、生物、计算机、体育等十几个学科的素材内容。

通用音效库（各种音效，无奇不有）：midi库、人类、动物、按钮、开头声、工具声、公共场所、广告、滑稽、家电、交通工具、警报、军事、卡通、乐器、情绪、日常生活、音乐、游戏音效、娱乐、运动、钟声、电报电话等。

通用图片库（精选后的高清晰度图片）：数十万幅按各种分类排列的JPG图片，可作为各学科的通用资源，也可供网站设计等方面使用。

CMS Author-Date Style，CSE Systems: Name-Year(N-Y) & Citation-Sequence(C-S)1.正文中的引证CMS Author-Date, N-Y两种格式注明出处时使用括号夹注的方法；C-S格式使用数字标注的方法。

（1）引用整篇文献的观点引用整篇文献（即全书或全文）观点时有两种情况，一种是作者的姓氏在正文中没有出现，如：CMS author-date:This procedure has been used successfully (Wong and Murphy 2001).N-Y:This procedure has been used successfully (Wong and Murphy 2001).C-S:This procedure has been used successfully[1].另一种情况是作者的姓氏已在正文同一句中出现，不需要使用括号夹注，如：CMS author-date:Wong and Murphy (2001) have used this procedure successfully.N-Y:Wong and Murphy (2001) have used this procedure successfully.在英文撰写的论文中引用中文著作或期刊，括号夹注中只需用汉语拼音标明作者的姓氏，不得使用汉字，如：(Zhu 2000)（2）引用文献中具体观点或文字引用文献中某一具体观点或文字时必须注明该观点或者该段文字出现的页码，没有页码是文献引用不规范的表现。

例如：CMS author-date:The results have been called “poppycock ” (Wilson 2009, 70).Wilson (2009, 70) has called the results “poppycock.”Wilson (2009) has called the results “poppycock”(70).N-Y:The results have been called “poppycock ” (Wilson 2009, p 70).Wilson (2009, p 70) has called the results “poppycock.”Wilson (2009) has called the results “poppycock”(p 70).如是同一作者的多卷本，则应在页码前加卷数，如是一本书的其中一个章节，则应加章节号，如是引用的图表，则应标注图表号。

教学资源标准格式1. 引言本文档旨在为教育机构和教师提供一种标准格式，以便有效管理和组织教学资源。

教学资源包括教材、课件、题、实验指导等内容。

通过采用标准格式，能够提高资源的质量、可靠性和可重复性。

2. 标准格式要求教学资源应按照以下要求进行标准化格式化：2.1 文件命名教学资源的文件名应简洁明了，以便快速辨识和查找。

建议采用以下命名方式：- 教材：科目名称_学年_版本号_章节名- 课件：科目名称_学年_版本号_主题名- 题：科目名称_学年_版本号_题类型- 实验指导：科目名称_学年_版本号_实验名称2.2 文件结构教学资源应按照统一的文件结构进行组织，方便学生和教师浏览和使用。

推荐以下文件结构：- 科目名称- 学年- 版本号- 章节名/主题名- 文件1- 文件2- ...2.3 文件格式教学资源的文件格式应与常见的办公软件兼容，并且易于阅读和编辑。

常用的文件格式包括：- 文本文档：.txt, .doc, .docx- 幻灯片：.ppt, .pptx- 表格：.xls, .xlsx- 图片：.jpg, .png, .gif2.4 版权声明所有教学资源应包含版权声明，以保护知识产权和合法使用。

版权声明应包括以下内容：- 作者姓名或机构名称- 版权所有年份- 权利声明3. 使用指南3.1 上传教学资源教师应根据标准格式，将所准备的教学资源上传至教育平台或学校系统，以便学生和其他教师获取和使用。

3.3 更学资源教师应及时更学资源，确保其内容和格式的准确性和完整性。

更新时应保持标准格式，并在文件名中注明版本号，便于跟踪和管理。

4. 总结通过遵循教学资源的标准格式要求，能够提高教学资源的管理效率和可用性，促进教学内容的质量和稳定性。

教育机构和教师应积极采用标准格式，有效地组织和利用教学资源，为学生提供更好的研究体验。

以上是教学资源标准格式的要求和使用指南。

通过统一的格式化，我们可以更好地管理和分享教学资源，提高教育教学的效果和效率。

Network Working Group G. Van de Velde Request for Comments: 5375 C. Popoviciu Category: Informational Cisco Systems T. Chown University of Southampton O. Bonness C. Hahn T-Systems Enterprise Services GmbH December 2008 IPv6 Unicast Address Assignment ConsiderationsStatus of This MemoThis memo provides information for the Internet community. It doesnot specify an Internet standard of any kind. Distribution of thismemo is unlimited.Copyright NoticeCopyright (c) 2008 IETF Trust and the persons identified as thedocument authors. All rights reserved.This document is subject to BCP 78 and the IETF Trust’s LegalProvisions Relating to IETF Documents (/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.AbstractOne fundamental aspect of any IP communications infrastructure is its addressing plan. With its new address architecture and allocationpolicies, the introduction of IPv6 into a network means that network designers and operators need to reconsider their existing approaches to network addressing. Lack of guidelines on handling this aspect of network design could slow down the deployment and integration ofIPv6. This document aims to provide the information andrecommendations relevant to planning the addressing aspects of IPv6deployments. The document also provides IPv6 addressing case studies for both an enterprise and an ISP network.Van de Velde, et al. Informational [Page 1]Table of Contents1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 32. Network-Level Addressing Design Considerations . . . . . . . . 4 2.1. Globally Unique Addresses . . . . . . . . . . . . . . . . 4 2.2. Unique Local IPv6 Addresses . . . . . . . . . . . . . . . 5 2.3. 6bone Address Space . . . . . . . . . . . . . . . . . . . 6 2.4. Network-Level Design Considerations . . . . . . . . . . . 6 2.4.1. Sizing the Network Allocation . . . . . . . . . . . . 82.4.2. Address Space Conservation . . . . . . . . . . . . . . 83. Subnet Prefix Considerations . . . . . . . . . . . . . . . . . 83.1. Considerations for /64 Prefixes . . . . . . . . . . . . . 104. Allocation of the IID of an IPv6 Address . . . . . . . . . . . 10 4.1. Automatic EUI-64 Format Option . . . . . . . . . . . . . . 10 4.2. Using Privacy Extensions . . . . . . . . . . . . . . . . . 104.3. Manual/Dynamic Assignment Option . . . . . . . . . . . . . 115. Security Considerations . . . . . . . . . . . . . . . . . . . 116. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 117. Informative References . . . . . . . . . . . . . . . . . . . . 12 Appendix A. Case Studies . . . . . . . . . . . . . . . . . . . . 16 A.1. Enterprise Considerations . . . . . . . . . . . . . . . . 16 A.1.1. Obtaining General IPv6 Network Prefixes . . . . . . . 16 A.1.2. Forming an Address (Subnet) Allocation Plan . . . . . 17 A.1.3. Other Considerations . . . . . . . . . . . . . . . . . 18 A.1.4. Node Configuration Considerations . . . . . . . . . . 18 A.2. Service Provider Considerations . . . . . . . . . . . . . 19 A.2.1. Investigation of Objective Requirements for anIPv6 Addressing Schema of a Service Provider . . . . . 19 A.2.2. Exemplary IPv6 Address Allocation Plan for aService Provider . . . . . . . . . . . . . . . . . . . 23 A.2.3. Additional Remarks . . . . . . . . . . . . . . . . . . 28 Appendix B. Considerations for Subnet Prefixes Different than/64 . . . . . . . . . . . . . . . . . . . . . . . . . 30 B.1. Considerations for Subnet Prefixes Shorter than /64 . . . 30 B.2. Considerations for Subnet Prefixes Longer than /64 . . . . 31 B.2.1. /126 Addresses . . . . . . . . . . . . . . . . . . . . 31 B.2.2. /127 Addresses . . . . . . . . . . . . . . . . . . . . 31 B.2.3. /128 Addresses . . . . . . . . . . . . . . . . . . . . 31 B.2.4. EUI-64 ’u’ and ’g’ Bits . . . . . . . . . . . . . . . 31 B.2.5. Anycast Addresses . . . . . . . . . . . . . . . . . . 32 B.2.6. Addresses Used by Embedded-RP (RFC 3956) . . . . . . . 33 B.2.7. ISATAP Addresses . . . . . . . . . . . . . . . . . . . 34 Van de Velde, et al. Informational [Page 2]1. IntroductionThe Internet Protocol Version 6 (IPv6) Addressing Architecture[RFC4291] defines three main types of addresses: unicast, anycast,and multicast. This document focuses on unicast addresses, for which there are currently two principal allocated types: Globally UniqueAddresses (’globals’) [RFC3587] and Unique Local IPv6 Addresses(ULAs) [RFC4193]. In addition, until recently there has been the’experimental’ 6bone address space [RFC3701], though its use has been deprecated since June 2006 [RFC3701].The document covers aspects that should be considered during IPv6deployment for the design and planning of an addressing scheme for an IPv6 network. The network’s IPv6 addressing plan may be for an IPv6- only network, or for a dual-stack infrastructure where some or alldevices have addresses in both protocols. These considerations will help an IPv6 network designer to efficiently and prudently assign the IPv6 address space that has been allocated to their organization.The address assignment considerations are analyzed separately for the two major components of the IPv6 unicast addresses -- namely,’Network-Level Addressing’ (the allocation of subnets) and the’interface-id’ (the identification of the interface within a subnet). Thus, the document includes a discussion of aspects of addressassignment to nodes and interfaces in an IPv6 network. Finally, the document provides two examples of deployed addressing plans in aservice provider (ISP) and an enterprise network.Parts of this document highlight the differences that an experienced IPv4 network designer should consider when planning an IPv6deployment, for example:o IPv6 devices will more likely be multi-addressed in comparisonwith their IPv4 counterparts.o The practically unlimited size of an IPv6 subnet (2^64 bits)reduces the requirement to size subnets to device counts for thepurposes of (IPv4) address conservation.o The vastly increased subnet size has implications on the threat of address-based host scanning and other scanning techniques, asdiscussed in [RFC5157].We do not discuss here how a site or ISP should proceed withacquiring its globally routable IPv6 address prefix. In each case,the prefix received is either provider assigned (PA) or providerindependent (PI).Van de Velde, et al. Informational [Page 3]We do not discuss PI policy here. The observations andrecommendations of this text are largely independent of the PA or PI nature of the address block being used. At this time, we assume that when an IPv6 network changes provider, typically it will need toundergo a renumbering process, as described in [RFC4192]. A separate document [THINKABOUT] makes recommendations to ease the IPv6renumbering process.This document does not discuss implementation aspects related to the transition from the now obsoleted site-local addresses to ULAs. Some implementations know about site-local addresses even though they are deprecated, and do not know about ULAs even though they representcurrent specification. As a result, transitioning between thesetypes of addresses may cause difficulties.2. Network-Level Addressing Design ConsiderationsThis section discusses the kind of IPv6 addresses used at the network level for the IPv6 infrastructure. The kind of addresses that can be considered are Globally Unique Addresses and ULAs. We also commenthere on the deprecated 6bone address space.2.1. Globally Unique AddressesThe most commonly used unicast addresses will be Globally UniqueAddresses (’globals’). No significant considerations are necessaryif the organization has an address space assignment and a singleprefix is deployed through a single upstream provider.However, a multihomed site may deploy addresses from two or moreservice-provider-assigned IPv6 address ranges. Here, the networkadministrator must have awareness on where and how these ranges areused on the multihomed infrastructure environment. The nature of the usage of multiple prefixes may depend on the reason for multihoming(e.g., resilience failover, load balancing, policy-based routing, or multihoming during an IPv6 renumbering event). IPv6 introducesimproved support for multi-addressed hosts through the IPv6 defaultaddress selection methods described in RFC 3484 [RFC3484]. Amultihomed host may thus have two or more addresses, one per prefix(provider), and select source and destination addresses to use asdescribed in that RFC. However, multihoming also has someoperational and administrative burdens besides choosing multipleaddresses per interface [RFC4218] [RFC4219].Van de Velde, et al. Informational [Page 4]2.2. Unique Local IPv6 AddressesULAs have replaced the originally conceived site-local addresses inthe IPv6 addressing architecture, for reasons described in [RFC3879]. ULAs improve on site-locals by offering a high probability of theglobal uniqueness of the prefix used, which can be beneficial whenthere is (deliberate or accidental) leakage or when networks aremerged. ULAs are akin to the private address space [RFC1918]assigned for IPv4 networks, except that in IPv6 networks we mayexpect to see ULAs used alongside global addresses, with ULAs usedinternally and globals used externally. Thus, use of ULAs does notimply use of NAT for IPv6.The ULA address range allows network administrators to deploy IPv6addresses on their network without asking for a globally uniqueregistered IPv6 address range. A ULA prefix is 48 bits, i.e., a /48, the same as the currently recommended allocation for a site from the globally routable IPv6 address space [RFC3177].A site that wishes to use ULAs can have (a) multiple /48 prefixes(e.g., a /44) (b) one /48, or (c) a less-than-/48 prefix (e.g., a /56 or /64). In all of the above cases, the ULAs can be randomly chosen according to the principles specified in [RFC4193]. However, in case (a) the use of randomly chosen ULAs will provide suboptimalaggregation capabilities.ULAs provide the means to deploy a fixed addressing scheme that isnot affected by a change in service provider and the corresponding PA global addresses. Internal operation of the network is thusunaffected during renumbering events. Nevertheless, this type ofaddress must be used with caution.A site using ULAs may or may not also deploy global addresses. In an isolated network, ULAs may be deployed on their own. In a connected network that also deploys global addresses, both may be deployed,such that hosts become multi-addressed (one global and one ULA), and the IPv6 default address selection algorithm will pick theappropriate source and destination addresses to use, e.g., ULAs will be selected where both the source and destination hosts have ULAs.Because a ULA and a global site prefix are both /48 length, anadministrator can choose to use the same subnetting (and hostaddressing) plan for both prefixes.As an example of the problems ULAs may cause, when using IPv6multicast within the network, the IPv6 default address selectionalgorithm prefers the ULA as the source address for the IPv6multicast streams. This is NOT a valid option when sending an IPv6multicast stream to the IPv6 Internet for two reasons. For one,Van de Velde, et al. Informational [Page 5]these addresses are not globally routable, so Reverse Path Forwarding checks for such traffic will fail outside the internal network. The other reason is that the traffic will likely not cross the networkboundary due to multicast domain control and perimeter securitypolicies.In principle, ULAs allow easier network mergers than RFC 1918addresses do for IPv4 because ULA prefixes have a high probability of uniqueness, if the prefix is chosen as described in the RFC.2.3. 6bone Address SpaceThe 6bone address space was used before the Regional InternetRegistries (RIRs) started to distribute ’production’ IPv6 prefixes.The 6bone prefixes have a common first 16 bits in the IPv6 Prefix of 3FFE::/16. This address range has been deprecated as of 6 June 2006 [RFC3701] and must not be used on any new IPv6 network deployments.Sites using 6bone address space should renumber to production address space using procedures as defined in [RFC4192].2.4. Network-Level Design ConsiderationsIPv6 provides network administrators with a significantly largeraddress space, enabling them to be very creative in how they candefine logical and practical addressing plans. The subnetting ofassigned prefixes can be done based on various logical schemes thatinvolve factors such as:o Using existing systems* translate the existing subnet numbers into IPv6 subnet IDs* translate the VLAN IDs into IPv6 subnet IDso Redesign* allocate according to your needo Aggregation* Geographical Boundaries - by assigning a common prefix to allsubnets within a geographical area.* Organizational Boundaries - by assigning a common prefix to an entire organization or group within a corporate infrastructure. Van de Velde, et al. Informational [Page 6]* Service Type - by reserving certain prefixes for predefinedservices such as: VoIP, content distribution, wirelessservices, Internet access, security areas, etc. This type ofaddressing may create dependencies on IP addresses that canmake renumbering harder if the nodes or interfaces supportingthose services on the network are sparse within the topology.Such logical addressing plans have the potential to simplify network operations and service offerings, and to simplify network management and troubleshooting. A very large network would not need to consider using private address space for its infrastructure devices, therebysimplifying network management.The network designer must however keep in mind several factors whendeveloping these new addressing schemes for networks with and without global connectivity:o Prefix aggregation - The larger IPv6 addresses can lead to larger routing tables unless network designers are actively pursuingaggregation. While prefix aggregation will be enforced by theservice provider, it is beneficial for the individualorganizations to observe the same principles in their networkdesign process.o Network growth - The allocation mechanism for flexible growth of a network prefix, documented in RFC 3531 [RFC3531] can be used toallow the network infrastructure to grow and be numbered in a way that is likely to preserve aggregation (the plan leaves ’holes’for growth).o ULA usage in large networks - Networks that have a large number of ’sites’ that each deploy a ULA prefix that will by default be a’random’ /48 under fc00::/7 will have no aggregation of thoseprefixes. Thus, the end result may be cumbersome because thenetwork will have large amounts of non-aggregated ULA prefixes.However, there is no rule to disallow large networks from using a single ULA prefix for all ’sites’, as a ULA still provides 16 bits for subnetting to be used internally.o Compact numbering of small sites - It is possible that as registry policies evolve, a small site may experience an increase in prefix length when renumbering, e.g., from /48 to /56. For this reason, the best practice is to number subnets compactly rather thansparsely, and to use low-order bits as much as possible whennumbering subnets. In other words, even if a /48 is allocated,act as though only a /56 is available. Clearly, this advice does not apply to large sites and enterprises that have an intrinsicneed for a /48 prefix.Van de Velde, et al. Informational [Page 7]o Consider assigning more than one /64 to a site - A small site may want to enable routing amongst interfaces connected to a gatewaydevice. For example, a residential gateway that receives a /48and is situated in a home with multiple LANs of different mediatypes (sensor network, wired, Wi-Fi, etc.), or has a need fortraffic segmentation (home, work, kids, etc.), could benefitgreatly from multiple subnets and routing in IPv6. Ideally,residential networks would be given an address range of a /48 or/56 [RIPE_Nov07] such that multiple /64 subnets could be usedwithin the residence.2.4.1. Sizing the Network AllocationWe do not discuss here how a network designer sizes their application for address space. By default, a site will receive a /48 prefix[RFC3177]; however, different RIR service regions policies maysuggest alternative default assignments or let the ISPs decide onwhat they believe is more appropriate for their specific case (seeSection 6.5.4, "Assignments from LIRs/ISPs", of [ARIN]). The default provider allocation via the RIRs is currently a /32 [RIPE_Nov07].These allocations are indicators for a first allocation for anetwork. Different sizes may be obtained based on the anticipatedaddress usage [RIPE_Nov07]. At the time of writing, there areexamples of allocations as large as /19 having been made from RIRs to providers.2.4.2. Address Space ConservationDespite the large IPv6 address space, which enables easiersubnetting, it still is important to ensure an efficient use of this resource. Some addressing schemes, while facilitating aggregationand management, could lead to significant numbers of addresses being unused. Address conservation requirements are less stringent inIPv6, but they should still be observed.The proposed Host-Density (HD) value [RFC3194] for IPv6 is 0.94compared to the current value of 0.96 for IPv4. Note that with IPv6, HD is calculated for sites (e.g., on a basis of /56), instead of for addresses as with IPv4.3. Subnet Prefix ConsiderationsAn important part of an IPv4 addressing plan is deciding the lengthof each subnet prefix. Unlike in IPv4, the IPv6 addressingarchitecture [RFC4291] specifies that all subnets using GloballyUnique Addresses and ULAs always have the same prefix length of 64bits. (This also applies to the deprecated 6bone and site-localaddresses.)Van de Velde, et al. Informational [Page 8]The only exception to this rule are special addresses starting withthe binary value 000, such as IPv4-compatible IPv6 addresses. These exceptions are largely beyond the scope of this document.Using a subnet prefix length other than a /64 will break manyfeatures of IPv6, including Neighbor Discovery (ND), Secure Neighbor Discovery (SEND) [RFC3971], privacy extensions [RFC4941], parts ofMobile IPv6 [RFC4866], Protocol Independent Multicast - Sparse Mode(PIM-SM) with Embedded-RP [RFC3956], and Site Multihoming by IPv6Intermediation (SHIM6) [SHIM6], among others. A number of otherfeatures currently in development, or being proposed, also rely on/64 subnet prefixes.Nevertheless, many IPv6 implementations do not prevent theadministrator from configuring a subnet prefix length shorter orlonger than 64 bits. Using subnet prefixes shorter than /64 wouldrarely be useful; see Appendix B.1 for discussion.However, some network administrators have used prefixes longer than/64 for links connecting routers, usually just two routers on apoint-to-point link. On links where all the addresses are assignedby manual configuration, and all nodes on the link are routers (notend hosts) that are known by the network, administrators do not need any of the IPv6 features that rely on /64 subnet prefixes, this canwork. Using subnet prefixes longer than /64 is not recommended forgeneral use, and using them for links containing end hosts would bean especially bad idea, as it is difficult to predict what IPv6features the hosts will use in the future.Appendix B.2 describes some practical considerations that need to be taken into account when using prefixes longer than /64 in limitedcases. In particular, a number of IPv6 features use interfaceidentifiers that have a special form (such as a certain fixed valuein some bit positions). When using prefixes longer than /64, it isprudent to avoid certain subnet prefix values so that nodes whoassume that the prefix is /64 will not incorrectly identify theaddresses in that subnet as having a special form. Appendix B.2describes the subnet prefix values that are currently believed to be potentially problematic; however, the list is not exhaustive and can be expected to grow in the future.Using /64 subnets is strongly recommended, also for links connecting only routers. A deployment compliant with the current IPv6specifications cannot use other prefix lengths. However, the V6OPSWG believes that despite the drawbacks (and a potentially expensivenetwork redesign, if IPv6 features relying on /64 subnets are needed in the future), some networks administrators will use prefixes longer than /64.Van de Velde, et al. Informational [Page 9]3.1. Considerations for /64 PrefixesBased on RFC 3177 [RFC3177], 64 bits is the prescribed subnet prefix length to allocate to interfaces and nodes.When using a /64 subnet length, the address assignment for theseaddresses can be made either by manual configuration, by a DynamicHost Configuration Protocol [RFC3315], by stateless autoconfiguration [RFC4862], or by a combination thereof [RFC3736].Note that RFC 3177 strongly prescribes 64-bit subnets for generalusage, and that stateless autoconfiguration on most link layers(including Ethernet) is only defined for 64-bit subnets. While intheory it might be possible that some future autoconfigurationmechanisms would allow longer than 64-bit prefix lengths to be used, the use of such prefixes is not recommended at this time.4. Allocation of the IID of an IPv6 AddressIn order to have a complete IPv6 address, an interface must beassociated with a prefix and an Interface Identifier (IID). Section 3 of this document analyzed the prefix selection considerations.This section discusses the elements that should be considered whenassigning the IID portion of the IPv6 address.There are various ways to allocate an IPv6 address to a device orinterface. The option with the least amount of caveats for thenetwork administrator is that of EUI-64 [RFC4862] based addresses.For the manual or dynamic options, the overlap with well-known IPv6addresses should be avoided.4.1. Automatic EUI-64 Format OptionWhen using this method, the network administrator has to allocate avalid 64-bit subnet prefix. Once that allocation has been made, the EUI-64 [RFC4862] allocation procedure can assign the remaining 64 IID bits in a stateless manner. All the considerations for selecting avalid IID have been incorporated into the EUI-64 methodology.4.2. Using Privacy ExtensionsThe main purpose of IIDs generated based on RFC 4941 [RFC4941] is to provide privacy to the entity using an IPv6 address. While there are no particular constraints in the usage of IPv6 addresses with IIDs as defined in [RFC4941], there are some implications to be aware of when using privacy addresses as documented in Section 4 of RFC 4941[RFC4941]Van de Velde, et al. Informational [Page 10]4.3. Manual/Dynamic Assignment OptionThis section discusses those IID allocations that are not implemented through stateless address configuration (Section 4.1). They areapplicable regardless of the prefix length used on the link. It isout of scope for this section to discuss the various assignmentmethods (e.g., manual configuration, DHCPv6, etc).In this situation, the actual allocation is done by humanintervention, and consideration needs to be given to the completeIPv6 address so that it does not result in overlaps with any of thewell-known IPv6 addresses:o Subnet Router Anycast Address (Appendix B.2.5.1)o Reserved Subnet Anycast Address (Appendix B.2.5.2)o Addresses used by Embedded-RP (Appendix B.2.6)o Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) Addresses (Appendix B.2.7)When using an address assigned by human intervention, it isrecommended to choose IPv6 addresses that are not obvious to guessand/or to avoid any IPv6 addresses that embed IPv4 addresses used in the current infrastructure. Following these two recommendations will make it more difficult for malicious third parties to guess targetsfor attack, and thus reduce security threats to a certain extent.5. Security ConsiderationsThis document doesn’t add any new security considerations that aren’t already outlined in the security considerations of the references.It must be noted that using subnet prefixes other than /64 breakssecurity mechanisms such as Cryptographically Generated Addresses(CGAs) and Hash-Based Addresses (HBAs), and thus makes it impossible to use protocols that depend on them.6. AcknowledgementsConstructive feedback and contributions have been received duringIESG review cycle and from Marla Azinger, Stig Venaas, Pekka Savola, John Spence, Patrick Grossetete, Carlos Garcia Braschi, BrianCarpenter, Mark Smith, Janos Mohacsi, Jim Bound, Fred Templin, Ginny Listman, Salman Assadullah, Krishnan Thirukonda, and the IESG.Van de Velde, et al. Informational [Page 11]7. Informative References[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot,G., and E. Lear, "Address Allocation for PrivateInternets", BCP 5, RFC 1918, February 1996.[RFC2526] Johnson, D. and S. Deering, "Reserved IPv6 SubnetAnycast Addresses", RFC 2526, March 1999.[RFC3021] Retana, A., White, R., Fuller, V., and D. McPherson, "Using 31-Bit Prefixes on IPv4 Point-to-Point Links", RFC 3021, December 2000.[RFC3053] Durand, A., Fasano, P., Guardini, I., and D. Lento,"IPv6 Tunnel Broker", RFC 3053, January 2001.[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6Domains via IPv4 Clouds", RFC 3056, February 2001.[RFC3177] IAB and IESG, "IAB/IESG Recommendations on IPv6Address Allocations to Sites", RFC 3177,September 2001.[RFC3180] Meyer, D. and P. Lothberg, "GLOP Addressing in233/8", BCP 53, RFC 3180, September 2001.[RFC3194] Durand, A. and C. Huitema, "The H-Density Ratio forAddress Assignment Efficiency An Update on the Hratio", RFC 3194, November 2001.[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins,C., and M. Carney, "Dynamic Host ConfigurationProtocol for IPv6 (DHCPv6)", RFC 3315, July 2003.[RFC3484] Draves, R., "Default Address Selection for InternetProtocol version 6 (IPv6)", RFC 3484, February 2003. [RFC3531] Blanchet, M., "A Flexible Method for Managing theAssignment of Bits of an IPv6 Address Block",RFC 3531, April 2003.[RFC3587] Hinden, R., Deering, S., and E. Nordmark, "IPv6Global Unicast Address Format", RFC 3587,August 2003.[RFC3627] Savola, P., "Use of /127 Prefix Length BetweenRouters Considered Harmful", RFC 3627,September 2003.Van de Velde, et al. Informational [Page 12][RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options forDynamic Host Configuration Protocol (DHCP) version6", RFC 3633, December 2003.[RFC3701] Fink, R. and R. Hinden, "6bone (IPv6 Testing Address Allocation) Phaseout", RFC 3701, March 2004.[RFC3736] Droms, R., "Stateless Dynamic Host ConfigurationProtocol (DHCP) Service for IPv6", RFC 3736,April 2004.[RFC3879] Huitema, C. and B. Carpenter, "Deprecating Site Local Addresses", RFC 3879, September 2004.[RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address",RFC 3956, November 2004.[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander,"SEcure Neighbor Discovery (SEND)", RFC 3971,March 2005.[RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures forRenumbering an IPv6 Network without a Flag Day",RFC 4192, September 2005.[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6Unicast Addresses", RFC 4193, October 2005.[RFC4218] Nordmark, E. and T. Li, "Threats Relating to IPv6Multihoming Solutions", RFC 4218, October 2005.[RFC4219] Lear, E., "Things Multihoming in IPv6 (MULTI6)Developers Should Think About", RFC 4219,October 2005.[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.[RFC4291] Hinden, R. and S. Deering, "IP Version 6 AddressingArchitecture", RFC 4291, February 2006.[RFC4477] Chown, T., Venaas, S., and C. Strauf, "Dynamic HostConfiguration Protocol (DHCP): IPv4 and IPv6 Dual-Stack Issues", RFC 4477, May 2006.Van de Velde, et al. Informational [Page 13]。

中国基础教育文献资源总库（CFED）简明使用手册《中国基础教育文献资源总库》(简称CFED)是经国家批准正式出版，以光盘和网络为载体，连续出版的国家级专业资源库，是国家新闻出版总署“十五”国家重点电子出版项目、“十一五”国家重大出版工程项目《中国知识资源总库》和中国知识基础设施工程（CNKI工程）的重要组成部分。

CFED以数字化方式全文收录我国基础教育领域的期刊、报纸、博硕士论文、会议论文等出版资源，是当前中国基础教育领域内，最具权威、文献信息量最全最大的动态资源系统，是中国最先进的基础教育知识服务与数字化学习平台。

它能有效地支持基础教育中的教育教学、科研选题、论文撰写、自主学习、研究性学习、教育管理、校本资源建设等活动，并可支持各级各类文献检索课程和信息素养课程的教学与研究。

CFED包括《中国基础教育期刊全文数据库》、《中国基础教育报纸全文数据库》、《中国基础教育博硕士学位论文全文数据库》、《中国基础教育会议论文全文数据库》等数据库。

1 开始使用数据库1.1登录数据库在浏览器的地址栏中输入网址http:// ，即可登陆CFED 主页。

1.2下载安装全文浏览器如果您是第一次使用CFED 的产品服务，那么您需要先下载并安装CAJViewer 浏览器才能看到文献的全文。

CFED 的所有文献都同时提供CAJ 和PDF 两种文件格式。

如果您习惯使用PDF ，则可以跳过此节。

我们推荐您使用速度更快、针对文献各种扩展功能更强的CAJ 浏览器。

具体步骤如下：1） 进入CFED 首页，在页面左侧“使用帮助”区下载阅读器，点击“CAJViewer7.2”进入下载页面。

2 如何利用CFED阅读期刊为满足用户阅读整刊（报、论文）的习惯，CFED对整刊（报、论文）进行了不同类型的划分，建立不同的分类体系。

下面以查找期刊为例，进行说明：1）登录CFED，在左侧数据库导航区，点击“期刊导航”，进入期刊导航检索页面。

2）在检索框内，输入所查找的期刊名称，如“中小学管理”。