rfc3228.IANA Considerations for IPv4 Internet Group Management Protocol (IGMP)
IPv4组播地址分配情况
IPv4 Multicast AddressSpace RegistryLast Updated2016-05-27NoteHost Extensions for IP Multicasting [RFC1112] specifies the extensionsrequired of a host implementation of the Internet Protocol (IP) tosupport multicasting. The multicast addresses are in the range224.0.0.0 through 239.255.255.255. Address assignments are listed below.The range of addresses between 224.0.0.0 and 224.0.0.255, inclusive,is reserved for the use of routing protocols and other low-leveltopology discovery or maintenance protocols, such as gateway discoveryand group membership reporting. Multicast routers should not forwardany multicast datagram with destination addresses in this range, regardless of its TTL.Registries included below●Local Network Control Block (224.0.0.0 - 224.0.0.255 (224.0.0/24))●Internetwork Control Block (224.0.1.0 - 224.0.1.255 (224.0.1/24))●AD-HOC Block I (224.0.2.0 - 224.0.255.255)●RESERVED (224.1.0.0-224.1.255.255 (224.1/16))●SDP/SAP Block (224.2.0.0-224.2.255.255 (224.2/16))●AD-HOC Block II (224.3.0.0-224.4.255.255 (224.3/16, 224.4/16))●RESERVED (224.5.0.0-224.251.255.255 (251 /16s))●DIS Transient Groups 224.252.0.0-224.255.255.255 (224.252/14))●RESERVED (225.0.0.0-231.255.255.255 (7 /8s))●Source-Specific Multicast Block (232.0.0.0-232.255.255.255 (232/8))●GLOP Block●AD-HOC Block III (233.252.0.0-233.255.255.255 (233.252/14))●Unicast-Prefix-based IPv4 Multicast Addresses●Scoped Multicast Ranges●Relative Addresses used with Scoped Multicast AddressesLocal Network Control Block (224.0.0.0 - 224.0.0.255 (224.0.0/24)) Registration Procedure(s)Expert Review, IESG Approval, or Standards ActionReference[RFC5771]Note(*) It is only appropriate to use these values in explicitly-configured experiments; they MUST NOT beInternetwork Control Block (224.0.1.0 - 224.0.1.255 (224.0.1/24)) Registration Procedure(s)Expert Review, IESG Approval, or Standards ActionReferenceAD-HOC Block I (224.0.2.0 - 224.0.255.255) Registration Procedure(s)Expert Review, IESG Approval, or Standards Action Reference[RFC5771]RESERVED (224.1.0.0-224.1.255.255 (224.1/16)) Reference[RFC5771]NoteNo new assignments are being made in this range for the time being.SDP/SAP Block (224.2.0.0-224.2.255.255 (224.2/16)) Reference[RFC5771]AD-HOC Block II (224.3.0.0-224.4.255.255 (224.3/16, 224.4/16)) Registration Procedure(s)Expert Review, IESG Approval, or Standards ActionReference[RFC5771]RESERVED (224.5.0.0-224.251.255.255 (251 /16s))Reference[RFC5771]DIS Transient Groups 224.252.0.0-224.255.255.255 (224.252/14))ReferenceRESERVED (225.0.0.0-231.255.255.255 (7 /8s))Reference[RFC5771]Source-Specific Multicast Block (232.0.0.0-232.255.255.255 (232/8))Reference[RFC5771]NoteAddresses within the 232.0.1.0-232.255.255.255 are dynamicallyallocated by hosts when needed [RFC4607]GLOP BlockReferenceAD-HOC Block III (233.252.0.0-233.255.255.255 (233.252/14)) Registration Procedure(s)Expert Review, IESG Approval, or Standards ActionReference[RFC5771]Unicast-Prefix-based IPv4 Multicast AddressesReference[RFC6034]Scoped Multicast RangesReference[RFC5771]Relative Addresses used with Scoped Multicast Addresses Reference[RFC5771]Note(*) It is only appropriate to use these values in explicitly-configured experiments; they MUST NOT be shipped as defaults inimplementations. See [RFC3692] for details.These addresses are listed in the Domain Name Service under and 224.IN-ADDR.ARPA. Note that when used on an Ethernet or IEEE 802 network, the 23low-order bits of the IP Multicast address are placed in the low-order23 bits of the Ethernet or IEEE 802 net multicast address1.0.94.0.0.0. See the section on "IANA ETHERNET ADDRESS BLOCK".。
IGMP_V3 中文
备忘录状态略摘要本文档说明了因特网组管理协议的第3版，IGMPv3。
IGMP协议被IPv4系统用于向邻接的多播路由器报告它们的组成员关系。
第3版的IGMP增加了对“源过滤”的支持，即系统能够报告它只对接收到的发往某一特定多播组的数据报中，某些来自特定源地址的数据感兴趣，或者是只对除了某些特定源地址之外的数据感兴趣。
这个信息能够被多播路由协议用于避免把某些来自特定源地址的多播数据报发往对它不感兴趣的网络。
1、简介IGMP协议被IPv4系统(主机或路由器)用于向邻接的多播路由器报告它们的组成员关系。
需要注意的是IP 多播路由器本身也可能是一个或多个多播组的成员。
在这种情况下，它会既执行协议的“多播路由器部分”(为它的多播路由协议收集成员信息)，又执行协议的“组成员部分”(把自己的成员关系通知自己，其它主机，还有邻接的多播路由器)。
IGMP协议还用于其它的IP多播管理功能，这通过使用组成员报告之外的其它的消息类型来实现。
这份文档只描述组成员关系报告功能和消息。
这份文档说明IGMP第3版。
第1版在RFC1112中说明，是第1个被广泛使用的版本，也是第1个成为因特网标准的版本。
第2版在RFC2236中说明，增加了对“低离开延迟”的支持，即多播路由器获知相连的网络中的某一个组中已经没有组成员所花费的时间大大减少。
而第3版增加了对“源过滤”的支持，即系统有能力报告对发往某个特定多播地址的数据报，只希望接收某些特定源的，以支持特定源多播[SSM]，或者只希望接收除了某些特定源的。
第3版被设计为能够跟第1版，第2版互操作的。
多播侦听者发现(MLD)是IPv6系统采用的一种相似的方法，MLD第1版实现了IGMP第2版的功能，MLD 第2版实现了IGMP第3版的功能。
2、用于IP多播接收的服务接口在一个IP系统内，有一个(至少概念上有)服务接口，被上层协议或者应用程序用于打开或者关闭IP层对发往某一特定IP多播地址的数据报的接收。
rfc3232.Assigned Numbers RFC 1700 is Replaced by an On-line Database
Network Working Group J. Reynolds, Editor Request for Comments: 3232 RFC Editor Obsoletes: 1700 January 2002 Category: InformationalAssigned Numbers: RFC 1700 is Replaced by an On-line DatabaseStatus 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) The Internet Society (2002). All Rights Reserved. AbstractThis memo obsoletes RFC 1700 (STD 2) "Assigned Numbers", whichcontained an October 1994 snapshot of assigned Internet protocolparameters.DescriptionFrom November 1977 through October 1994, the Internet AssignedNumbers Authority (IANA) periodically published tables of theInternet protocol parameter assignments in RFCs entitled, "AssignedNumbers". The most current of these Assigned Numbers RFCs hadStandard status and carried the designation: STD 2. At this time,the latest STD 2 is RFC 1700.Since 1994, this sequence of RFCs have been replaced by an onlinedatabase accessible through a web page (currently, ).The purpose of the present RFC is to note this fact and to officially obsolete RFC 1700, whose status changes to Historic. RFC 1700 isobsolete, and its values are incomplete and in some cases may bewrong.We expect this series to be revived in the future by the new IANAorganization.Security ConsiderationsThis memo does not affect the technical security of the Internet. Reynolds Informational [Page 1]Author’s AddressJoyce K. ReynoldsRFC Editor4676 Admiralty WayMarina del Rey, CA 90292USAEMail: rfc-editor@Reynolds Informational [Page 2]Full Copyright StatementCopyright (C) The Internet Society (2002). All Rights Reserved.This document and translations of it may be copied and furnished toothers, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, publishedand distributed, in whole or in part, without restriction of anykind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, thisdocument itself may not be modified in any way, such as by removingthe copyright notice or references to the Internet Society or otherInternet organizations, except as needed for the purpose ofdeveloping Internet standards in which case the procedures forcopyrights defined in the Internet Standards process must befollowed, or as required to translate it into languages other thanEnglish.The limited permissions granted above are perpetual and will not berevoked by the Internet Society or its successors or assigns.This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERINGTASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDINGBUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATIONHEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OFMERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.AcknowledgementFunding for the RFC Editor function is currently provided by theInternet Society.Reynolds Informational [Page 3]。
中移动家庭网关终端技术规范v
中国移动通信企业标准QB-╳╳-╳╳╳-╳╳╳╳家庭网关终端技术规范T e c h n i c a l S p e c i f i c a t i o n f o r H o m e G a t e w a y版本号：3.0.0╳╳╳╳-╳╳-╳╳发布╳╳╳╳-╳╳-╳╳实施中国移动通信集团公司发布目录1. 范围 ................................................................................................................................................2. 规范性引用文件 .............................................................................................................................3. 术语、定义和缩略语 .....................................................................................................................4. 设备总体定义.................................................................................................................................4.1.设备在网络中的位置 ..................................................................................................................4.2.接口定义 ......................................................................................................................................4.3.设备类型 ......................................................................................................................................5. 接入型家庭网关 .............................................................................................................................5.1.接口要求 ......................................................................................................................................网络侧接口......................................................................................................................................网络侧接口描述..........................................................................................................................................网络侧以太网接口要求..............................................................................................................................接口要求 .......................................................................................................................................................接口要求 .......................................................................................................................................................接口要求 .......................................................................................................................................................用户侧接口......................................................................................................................................用户侧以太网接口要求..............................................................................................................................接口 ...............................................................................................................................................................接口（可选）................................................................................................................................................5.2.功能要求 ......................................................................................................................................数据通信要求..................................................................................................................................协议要求 .......................................................................................................................................................数据转发功能要求......................................................................................................................................功能要求 .......................................................................................................................................................地址管理及拨号管理功能要求....................................................................................................................地址管理及拨号管理功能要求....................................................................................................................要求 ...............................................................................................................................................................要求 ...............................................................................................................................................................组播要求 .....................................................................................................................................................其他功能要求..............................................................................................................................................安全要求..........................................................................................................................................防火墙 .........................................................................................................................................................登陆WEB页面的安全要求..........................................................................................................................设备安全性 .................................................................................................................................................要求....................................................................................................................................................功能要求............................................................................................................................................扩展及管理（可选）........................................................................................................................设备发现要求.........................................................................................................................................................................................................................................................................................................（可选） .......................................................................................................................................................支持WLAN的开启和禁用............................................................................................................................基本要求 .....................................................................................................................................................多SSID要求................................................................................................................................................安全要求 .......................................................................................................................................................5要求 ............................................................................................................................................................要求 ...............................................................................................................................................................基本应用要求................................................................................................................................... WLAN共享 ..................................................................................................................................................家庭存储（可选）......................................................................................................................................5.3.性能要求 ......................................................................................................................................路由转发性能要求..........................................................................................................................吞吐量 .........................................................................................................................................................地址学习 .....................................................................................................................................................缓存大小 (23)连接数量要求.............................................................................................................................................. 无线性能要求....................................................................................................................................吞吐量性能要求 (23)覆盖性能要求................................................................................................................................................接收灵敏度要求............................................................................................................................................5.4.管理和维护要求 (24)本地管理和配置要求......................................................................................................................本地管理基本要求......................................................................................................................................用户分级管理 (24)系统信息管理..............................................................................................................................................基本配置 .....................................................................................................................................................高级配置 .....................................................................................................................................................设备管理 .....................................................................................................................................................网络诊断 .....................................................................................................................................................设备认证注册功能......................................................................................................................................远程管理要求..................................................................................................................................远程管理基本要求......................................................................................................................................远程参数配置和性能监测..........................................................................................................................远程故障诊断功能......................................................................................................................................设备告警功能..............................................................................................................................................远程链路维持功能......................................................................................................................................软件远程管理..............................................................................................................................................业务部署和控制..........................................................................................................................................上行家庭网关远程管理实现方式 ................................................................................................................日志功能要求..................................................................................................................................5.5.预配置要求 ..................................................................................................................................预配置要求......................................................................................................................................5.6.硬件要求 ......................................................................................................................................基本要求..........................................................................................................................................硬件基本框图示例..........................................................................................................................5.7.软件要求 ......................................................................................................................................基本要求..........................................................................................................................................软件基本架构................................................................................................. 错误!未定义书签。
rfc3123.A DNS RR Type for Lists of Address Prefixes (APL RR)
Network Working Group P. Koch Request for Comments: 3123 Universitaet Bielefeld Category: Experimental June 2001 A DNS RR Type for Lists of Address Prefixes (APL RR)Status of this MemoThis memo defines an Experimental Protocol for the Internetcommunity. It does not specify an Internet standard of any kind.Discussion and suggestions for improvement are requested.Distribution of this memo is unlimited.Copyright NoticeCopyright (C) The Internet Society (2001). All Rights Reserved. AbstractThe Domain Name System (DNS) is primarily used to translate domainnames into IPv4 addresses using A RRs (Resource Records). Severalapproaches exist to describe networks or address ranges. Thisdocument specifies a new DNS RR type "APL" for address prefix lists.1. Conventions used in this documentThe key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].Domain names herein are for explanatory purposes only and should not be expected to lead to useful information in real life [RFC2606].2. BackgroundThe Domain Name System [RFC1034], [RFC1035] provides a mechanism toassociate addresses and other Internet infrastructure elements withhierarchically built domain names. Various types of resource records have been defined, especially those for IPv4 and IPv6 [RFC2874]addresses. In [RFC1101] a method is described to publish information about the address space allocated to an organisation. In older BIND versions, a weak form of controlling access to zone data wasimplemented using TXT RRs describing address ranges.This document specifies a new RR type for address prefix lists.Koch Experimental [Page 1]3. APL RR TypeAn APL record has the DNS type of "APL" and a numeric value of 42[IANA]. The APL RR is defined in the IN class only. APL RRs causeno additional section processing.4. APL RDATA formatThe RDATA section consists of zero or more items (<apitem>) of theform+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ | ADDRESSFAMILY | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ | PREFIX | N | AFDLENGTH | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ / AFDPART / | | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ ADDRESSFAMILY 16 bit unsigned value as assigned by IANA(see IANA Considerations)PREFIX 8 bit unsigned binary coded prefix length.Upper and lower bounds and interpretation ofthis value are address family specific.N negation flag, indicates the presence of the"!" character in the textual format. It hasthe value "1" if the "!" was given, "0" else.AFDLENGTH length in octets of the following addressfamily dependent part (7 bit unsigned).AFDPART address family dependent part. See below.This document defines the AFDPARTs for address families 1 (IPv4) and 2 (IPv6). Future revisions may deal with additional addressfamilies.4.1. AFDPART for IPv4The encoding of an IPv4 address (address family 1) follows theencoding specified for the A RR by [RFC1035], section 3.4.1.PREFIX specifies the number of bits of the IPv4 address starting atthe most significant bit. Legal values range from 0 to 32.Trailing zero octets do not bear any information (e.g., there is nosemantic difference between 10.0.0.0/16 and 10/16) in an addressprefix, so the shortest possible AFDLENGTH can be used to encode it. However, for DNSSEC [RFC2535] a single wire encoding must be used by Koch Experimental [Page 2]all. Therefore the sender MUST NOT include trailing zero octets inthe AFDPART regardless of the value of PREFIX. This includes casesin which AFDLENGTH times 8 results in a value less than PREFIX. The AFDPART is padded with zero bits to match a full octet boundary.An IPv4 AFDPART has a variable length of 0 to 4 octets.4.2. AFDPART for IPv6The 128 bit IPv6 address (address family 2) is encoded in networkbyte order (high-order byte first).PREFIX specifies the number of bits of the IPv6 address starting atthe most significant bit. Legal values range from 0 to 128.With the same reasoning as in 4.1 above, the sender MUST NOT include trailing zero octets in the AFDPART regardless of the value ofPREFIX. This includes cases in which AFDLENGTH times 8 results in a value less than PREFIX. The AFDPART is padded with zero bits tomatch a full octet boundary.An IPv6 AFDPART has a variable length of 0 to 16 octets.5. Zone File SyntaxThe textual representation of an APL RR in a DNS zone file is asfollows:<owner> IN <TTL> APL {[!]afi:address/prefix}*The data consists of zero or more strings of the address familyindicator <afi>, immediately followed by a colon ":", an address,immediately followed by the "/" character, immediately followed by a decimal numeric value for the prefix length. Any such string may be preceded by a "!" character. The strings are separated bywhitespace. The <afi> is the decimal numeric value of thatparticular address family.5.1. Textual Representation of IPv4 AddressesAn IPv4 address in the <address> part of an <apitem> is in dottedquad notation, just as in an A RR. The <prefix> has values from the interval 0..32 (decimal).Koch Experimental [Page 3]5.2. Textual Representation of IPv6 AddressesThe representation of an IPv6 address in the <address> part of an<apitem> follows [RFC2373], section 2.2. Legal values for <prefix>are from the interval 0..128 (decimal).6. APL RR usageAn APL RR with empty RDATA is valid and implements an empty list.Multiple occurrences of the same <apitem> in a single APL RR areallowed and MUST NOT be merged by a DNS server or resolver.<apitems> MUST be kept in order and MUST NOT be rearranged oraggregated.A single APL RR may contain <apitems> belonging to different address families. The maximum number of <apitems> is upper bounded by theavailable RDATA space.RRSets consisting of more than one APL RR are legal but theinterpretation is left to the particular application.7. Applicability StatementThe APL RR defines a framework without specifying any particularmeaning for the list of prefixes. It is expected that APL RRs willbe used in different application scenarios which have to bedocumented separately. Those scenarios may be distinguished bycharacteristic prefixes placed in front of the DNS owner name.An APL application specification MUST include information ono the characteristic prefix, if anyo how to interpret APL RRSets consisting of more than one RRo how to interpret an empty APL RRo which address families are expected to appear in the APL RRs forthat applicationo how to deal with APL RR list elements which belong to otheraddress families, including those not yet definedo the exact semantics of list elements negated by the "!" character Koch Experimental [Page 4]Possible applications include the publication of address rangessimilar to [RFC1101], description of zones built following [RFC2317] and in-band access control to limit general access or zone transfer(AXFR) availability for zone data held in DNS servers.The specification of particular application scenarios is out of thescope of this document.8. ExamplesThe following examples only illustrate some of the possible usagesoutlined in the previous section. None of those applications arehereby specified nor is it implied that any particular APL RR basedapplication does exist now or will exist in the future.; RFC 1101-like announcement of address ranges for foo.examplefoo.example. IN APL 1:192.168.32.0/21 !1:192.168.38.0/28; CIDR blocks covered by classless delegation42.168.192.IN-ADDR.ARPA. IN APL ( 1:192.168.42.0/26 1:192.168.42.64/26 1:192.168.42.128/25 ); Zone transfer restriction_axfr.sbo.example. IN APL 1:127.0.0.1/32 1:172.16.64.0/22; List of address ranges for multicastmulticast.example. IN APL 1:224.0.0.0/4 2:FF00:0:0:0:0:0:0:0/8 Note that since trailing zeroes are ignored in the first APL RR theAFDLENGTH of both <apitems> is three.9. Security ConsiderationsAny information obtained from the DNS should be regarded as unsafeunless techniques specified in [RFC2535] or [RFC2845] were used. The definition of a new RR type does not introduce security problems into the DNS, but usage of information made available by APL RRs maycompromise security. This includes disclosure of network topologyinformation and in particular the use of APL RRs to construct access control lists.Koch Experimental [Page 5]10. IANA ConsiderationsThis section is to be interpreted as following [RFC2434].This document does not define any new namespaces. It uses the 16 bit identifiers for address families maintained by IANA in/numbers.html.The IANA assigned numeric RR type value 42 for APL [IANA].11. AcknowledgementsThe author would like to thank Mark Andrews, Olafur Gudmundsson, EdLewis, Thomas Narten, Erik Nordmark, and Paul Vixie for their review and constructive comments.12. References[RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities", STD 13, RFC 1034, November 1987.[RFC1035] Mockapetris, P., "Domain Names - Implementation andSpecification", STD 13, RFC 1035, November 1987.[RFC1101] Mockapetris, P., "DNS Encoding of Network Names and OtherTypes", RFC 1101, April 1989.[RFC2119] Bradner, S., "Key words for use in RFCs to IndicateRequirement Levels", BCP 14, RFC 2119, March 1997.[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNSSpecification", RFC 2181, July 1997.[RFC2317] Eidnes, H., de Groot, G. and P. Vixie, "Classless IN-ADDR.ARPA delegation", BCP 20, RFC 2317, March 1998.[RFC2373] Hinden, R. and S. Deering, "IP Version 6 AddressingArchitecture", RFC 2373, July 1998.[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing anIANA Considerations Section in RFCs", BCP 26, RFC 2434,October 1998.[RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999.[RFC2606] Eastlake, D. and A. Panitz, "Reserved Top Level DNS Names", BCP 32, RFC 2606, June 1999.Koch Experimental [Page 6][RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington, "Secret Key Transaction Authentication for DNS (TSIG)", RFC 2845, May 2000.[RFC2874] Crawford, M. and C. Huitema, "DNS Extensions to SupportIPv6 Address Aggregation and Renumbering", RFC 2874, July2000.[IANA] /assignments/dns-parameters13. Author’s AddressPeter KochUniversitaet BielefeldTechnische FakultaetD-33594 BielefeldGermanyPhone: +49 521 106 2902EMail: pk@TechFak.Uni-Bielefeld.DEKoch Experimental [Page 7]14. Full Copyright StatementCopyright (C) The Internet Society (2001). All Rights Reserved.This document and translations of it may be copied and furnished toothers, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, publishedand distributed, in whole or in part, without restriction of anykind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, thisdocument itself may not be modified in any way, such as by removingthe copyright notice or references to the Internet Society or otherInternet organizations, except as needed for the purpose ofdeveloping Internet standards in which case the procedures forcopyrights defined in the Internet Standards process must befollowed, or as required to translate it into languages other thanEnglish.The limited permissions granted above are perpetual and will not berevoked by the Internet Society or its successors or assigns.This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERINGTASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDINGBUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATIONHEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OFMERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.AcknowledgementFunding for the RFC Editor function is currently provided by theInternet Society.Koch Experimental [Page 8]。
常用IP协议号
32
MERIT-INPMERIT节点间协议
MERIT Internodal Protocol
[HWB]
33
DCCP数据报拥塞控制协议
Datagram Congestion Control Protocol
[RFC-ietf-dccp-spec-11.txt]
34
3PC第三方连接协议
Source Demand Routing Protocol
[DXE1]
43
IPv6-RouteIPv6的路由标头
Routing Header for IPv6
[Deering]
44
IPv6-FragIPv6的片断标头
Fragment Header for IPv6
[Deering]
45
IDRP域间路由协议
常用IP协议号
协议号
协议名
协议名称解释
参考标准
0
HOPOPT逐跳选项
IPv6Hop-by-HopOption
[RFC1883]
1
ICMP控制消息
Internet Control Message
[RFC792]
2
IGMP组管理
Internet Group Management
[RFC1112]
3
GGP网关对网关
[David Johnson]
49
BNA
BNA
[Gary Salamon]
50
ESPIPv6的封装安全负载
Encap Security Payload
[RFC2406]
51
AHIPv6的身份验证标头
Authentication Header
和SIP有关的RFC
RFC 3680 SIP Event Package for Registrations
RFC 3702 Authentication, Authorization, and Accounting Requirements for the SIP
RFC 3515 The Session Initiation Protocol (SIP) Refer Method
RFC 3578 Mapping of Integrated Services Digital Network (ISDN) User Part (ISUP) Overlap Signalling to the SIP
RFC 4244 An Extension to the SIP for Request History Information
RFC 4245 High-Level Requirements for Tightly Coupled SIP Conferencing
RFC 4320 Actions Addressing Identified Issues with the SIP's Non-INVITE Transaction
RFC 3581 An Extension to the SIP for Symmetric Response Routing
RFC 3603 Private SIP Proxy-to-Proxy Extensions for Supporting the PacketCable Distributed Call Signaling Architecture.
rfc5288.AES Galois Counter Mode (GCM) Cipher Suites for TLS
Network Working Group J. Salowey Request for Comments: 5288 A. Choudhury Category: Standards Track D. McGrew Cisco Systems, Inc. August 2008 AES Galois Counter Mode (GCM) Cipher Suites for TLSStatus of This MemoThis document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions forimprovements. Please refer to the current edition of the "InternetOfficial Protocol Standards" (STD 1) for the standardization stateand status of this protocol. Distribution of this memo is unlimited.AbstractThis memo describes the use of the Advanced Encryption Standard (AES) in Galois/Counter Mode (GCM) as a Transport Layer Security (TLS)authenticated encryption operation. GCM provides bothconfidentiality and data origin authentication, can be efficientlyimplemented in hardware for speeds of 10 gigabits per second andabove, and is also well-suited to software implementations. Thismemo defines TLS cipher suites that use AES-GCM with RSA, DSA, andDiffie-Hellman-based key exchange mechanisms.Table of Contents1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 22. Conventions Used in This Document . . . . . . . . . . . . . . . 23. AES-GCM Cipher Suites . . . . . . . . . . . . . . . . . . . . . 24. TLS Versions . . . . . . . . . . . . . . . . . . . . . . . . . 35. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 46. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 6.1. Counter Reuse . . . . . . . . . . . . . . . . . . . . . . . 46.2. Recommendations for Multiple Encryption Processors . . . . 47. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 58. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 8.1. Normative References . . . . . . . . . . . . . . . . . . . 6 8.2. Informative References . . . . . . . . . . . . . . . . . . 6 Salowey, et al. Standards Track [Page 1]1. IntroductionThis document describes the use of AES [AES] in Galois Counter Mode(GCM) [GCM] (AES-GCM) with various key exchange mechanisms as acipher suite for TLS. AES-GCM is an authenticated encryption withassociated data (AEAD) cipher (as defined in TLS 1.2 [RFC5246])providing both confidentiality and data origin authentication. Thefollowing sections define cipher suites based on RSA, DSA, andDiffie-Hellman key exchanges; ECC-based (Elliptic Curve Cryptography) cipher suites are defined in a separate document [RFC5289].AES-GCM is not only efficient and secure, but hardwareimplementations can achieve high speeds with low cost and lowlatency, because the mode can be pipelined. Applications thatrequire high data throughput can benefit from these high-speedimplementations. AES-GCM has been specified as a mode that can beused with IPsec ESP [RFC4106] and 802.1AE Media Access Control (MAC) Security [IEEE8021AE].2. Conventions Used in This DocumentThe key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].3. AES-GCM Cipher SuitesThe following cipher suites use the new authenticated encryptionmodes defined in TLS 1.2 with AES in Galois Counter Mode (GCM) [GCM]: CipherSuite TLS_RSA_WITH_AES_128_GCM_SHA256 = {0x00,0x9C}CipherSuite TLS_RSA_WITH_AES_256_GCM_SHA384 = {0x00,0x9D}CipherSuite TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 = {0x00,0x9E}CipherSuite TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 = {0x00,0x9F}CipherSuite TLS_DH_RSA_WITH_AES_128_GCM_SHA256 = {0x00,0xA0}CipherSuite TLS_DH_RSA_WITH_AES_256_GCM_SHA384 = {0x00,0xA1}CipherSuite TLS_DHE_DSS_WITH_AES_128_GCM_SHA256 = {0x00,0xA2}CipherSuite TLS_DHE_DSS_WITH_AES_256_GCM_SHA384 = {0x00,0xA3}CipherSuite TLS_DH_DSS_WITH_AES_128_GCM_SHA256 = {0x00,0xA4}CipherSuite TLS_DH_DSS_WITH_AES_256_GCM_SHA384 = {0x00,0xA5}CipherSuite TLS_DH_anon_WITH_AES_128_GCM_SHA256 = {0x00,0xA6}CipherSuite TLS_DH_anon_WITH_AES_256_GCM_SHA384 = {0x00,0xA7}These cipher suites use the AES-GCM authenticated encryption withassociated data (AEAD) algorithms AEAD_AES_128_GCM andAEAD_AES_256_GCM described in [RFC5116]. Note that each of theseAEAD algorithms uses a 128-bit authentication tag with GCM (inparticular, as described in Section 3.5 of [RFC4366], theSalowey, et al. Standards Track [Page 2]"truncated_hmac" extension does not have an effect on cipher suitesthat do not use HMAC). The "nonce" SHALL be 12 bytes long consisting of two parts as follows: (this is an example of a "partiallyexplicit" nonce; see Section 3.2.1 in [RFC5116]).struct {opaque salt[4];opaque nonce_explicit[8];} GCMNonce;The salt is the "implicit" part of the nonce and is not sent in thepacket. Instead, the salt is generated as part of the handshakeprocess: it is either the client_write_IV (when the client issending) or the server_write_IV (when the server is sending). Thesalt length (SecurityParameters.fixed_iv_length) is 4 octets.The nonce_explicit is the "explicit" part of the nonce. It is chosen by the sender and is carried in each TLS record in theGenericAEADCipher.nonce_explicit field. The nonce_explicit length(SecurityParameters.record_iv_length) is 8 octets.Each value of the nonce_explicit MUST be distinct for each distinctinvocation of the GCM encrypt function for any fixed key. Failure to meet this uniqueness requirement can significantly degrade security. The nonce_explicit MAY be the 64-bit sequence number.The RSA, DHE_RSA, DH_RSA, DHE_DSS, DH_DSS, and DH_anon key exchanges are performed as defined in [RFC5246].The Pseudo Random Function (PRF) algorithms SHALL be as follows:For cipher suites ending with _SHA256, the PRF is the TLS PRF[RFC5246] with SHA-256 as the hash function.For cipher suites ending with _SHA384, the PRF is the TLS PRF[RFC5246] with SHA-384 as the hash function.Implementations MUST send TLS Alert bad_record_mac for all types offailures encountered in processing the AES-GCM algorithm.4. TLS VersionsThese cipher suites make use of the authenticated encryption withadditional data defined in TLS 1.2 [RFC5246]. They MUST NOT benegotiated in older versions of TLS. Clients MUST NOT offer thesecipher suites if they do not offer TLS 1.2 or later. Servers thatselect an earlier version of TLS MUST NOT select one of these cipher suites. Because TLS has no way for the client to indicate that it Salowey, et al. Standards Track [Page 3]supports TLS 1.2 but not earlier, a non-compliant server mightpotentially negotiate TLS 1.1 or earlier and select one of the cipher suites in this document. Clients MUST check the TLS version andgenerate a fatal "illegal_parameter" alert if they detect anincorrect version.5. IANA ConsiderationsIANA has assigned the following values for the cipher suites defined in this document:CipherSuite TLS_RSA_WITH_AES_128_GCM_SHA256 = {0x00,0x9C}CipherSuite TLS_RSA_WITH_AES_256_GCM_SHA384 = {0x00,0x9D}CipherSuite TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 = {0x00,0x9E}CipherSuite TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 = {0x00,0x9F}CipherSuite TLS_DH_RSA_WITH_AES_128_GCM_SHA256 = {0x00,0xA0}CipherSuite TLS_DH_RSA_WITH_AES_256_GCM_SHA384 = {0x00,0xA1}CipherSuite TLS_DHE_DSS_WITH_AES_128_GCM_SHA256 = {0x00,0xA2}CipherSuite TLS_DHE_DSS_WITH_AES_256_GCM_SHA384 = {0x00,0xA3}CipherSuite TLS_DH_DSS_WITH_AES_128_GCM_SHA256 = {0x00,0xA4}CipherSuite TLS_DH_DSS_WITH_AES_256_GCM_SHA384 = {0x00,0xA5}CipherSuite TLS_DH_anon_WITH_AES_128_GCM_SHA256 = {0x00,0xA6}CipherSuite TLS_DH_anon_WITH_AES_256_GCM_SHA384 = {0x00,0xA7}6. Security ConsiderationsThe security considerations in [RFC5246] apply to this document aswell. The remainder of this section describes securityconsiderations specific to the cipher suites described in thisdocument.6.1. Counter ReuseAES-GCM security requires that the counter is never reused. The IVconstruction in Section 3 is designed to prevent counter reuse.Implementers should also understand the practical considerations ofIV handling outlined in Section 9 of [GCM].6.2. Recommendations for Multiple Encryption ProcessorsIf multiple cryptographic processors are in use by the sender, thenthe sender MUST ensure that, for a particular key, each value of the nonce_explicit used with that key is distinct. In this case, eachencryption processor SHOULD include, in the nonce_explicit, a fixedvalue that is distinct for each processor. The recommended format is nonce_explicit = FixedDistinct || VariableSalowey, et al. Standards Track [Page 4]where the FixedDistinct field is distinct for each encryptionprocessor, but is fixed for a given processor, and the Variable field is distinct for each distinct nonce used by a particular encryptionprocessor. When this method is used, the FixedDistinct fields usedby the different processors MUST have the same length.In the terms of Figure 2 in [RFC5116], the Salt is the Fixed-Commonpart of the nonce (it is fixed, and it is common across allencryption processors), the FixedDistinct field exactly correspondsto the Fixed-Distinct field, the Variable field corresponds to theCounter field, and the explicit part exactly corresponds to thenonce_explicit.For clarity, we provide an example for TLS in which there are twodistinct encryption processors, each of which uses a one-byteFixedDistinct field:Salt = eedc68dcFixedDistinct = 01 (for the first encryption processor) FixedDistinct = 02 (for the second encryption processor)The GCMnonces generated by the first encryption processor, and their corresponding nonce_explicit, are:GCMNonce nonce_explicit------------------------ ----------------------------eedc68dc0100000000000000 0100000000000000eedc68dc0100000000000001 0100000000000001eedc68dc0100000000000002 0100000000000002...The GCMnonces generated by the second encryption processor, and their corresponding nonce_explicit, areGCMNonce nonce_explicit------------------------ ----------------------------eedc68dc0200000000000000 0200000000000000eedc68dc0200000000000001 0200000000000001eedc68dc0200000000000002 0200000000000002...7. AcknowledgementsThis document borrows heavily from [RFC5289]. The authors would like to thank Alex Lam, Simon Josefsson, and Pasi Eronen for providinguseful comments during the review of this document.Salowey, et al. Standards Track [Page 5]8. References8.1. Normative References[AES] National Institute of Standards and Technology,"Advanced Encryption Standard (AES)", FIPS 197,November 2001.[GCM] Dworkin, M., "Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC",National Institute of Standards and Technology SP 800- 38D, November 2007.[RFC2119] Bradner, S., "Key words for use in RFCs to IndicateRequirement Levels", BCP 14, RFC 2119, March 1997.[RFC5116] McGrew, D., "An Interface and Algorithms forAuthenticated Encryption", RFC 5116, January 2008.[RFC5246] Dierks, T. and E. Rescorla, "The Transport LayerSecurity (TLS) Protocol Version 1.2", RFC 5246,August 2008.8.2. Informative References[IEEE8021AE] Institute of Electrical and Electronics Engineers,"Media Access Control Security", IEEE Standard 802.1AE, August 2006.[RFC4106] Viega, J. and D. McGrew, "The Use of Galois/CounterMode (GCM) in IPsec Encapsulating Security Payload(ESP)", RFC 4106, June 2005.[RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and T. Wright, "Transport Layer Security (TLS)Extensions", RFC 4366, April 2006.[RFC5289] Rescorla, E., "TLS Elliptic Curve Cipher Suites withSHA-256/384 and AES Galois Counter Mode", RFC 5289,August 2008.Salowey, et al. Standards Track [Page 6]Authors’ AddressesJoseph SaloweyCisco Systems, Inc.2901 3rd. AveSeattle, WA 98121USAEMail: jsalowey@Abhijit ChoudhuryCisco Systems, Inc.3625 Cisco WaySan Jose, CA 95134USAEMail: abhijitc@David McGrewCisco Systems, Inc.170 W Tasman DriveSan Jose, CA 95134USAEMail: mcgrew@Salowey, et al. Standards Track [Page 7]Full Copyright StatementCopyright (C) The IETF Trust (2008).This document is subject to the rights, licenses and restrictionscontained in BCP 78, and except as set forth therein, the authorsretain all their rights.This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIEDWARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual PropertyThe IETF takes no position regarding the validity or scope of anyIntellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described inthis document or the extent to which any license under such rightsmight or might not be available; nor does it represent that it hasmade any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can befound in BCP 78 and BCP 79.Copies of IPR disclosures made to the IETF Secretariat and anyassurances of licenses to be made available, or the result of anattempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of thisspecification can be obtained from the IETF on-line IPR repository at /ipr.The IETF invites any interested party to bring to its attention anycopyrights, patents or patent applications, or other proprietaryrights that may cover technology that may be required to implementthis standard. Please address the information to the IETF atietf-ipr@.Salowey, et al. Standards Track [Page 8]。
协议号大全
协议号大全协议号大全Decimal Keyword Protocol References -------- ------------- ---------------------------- ----------------0 HOPOPT IPv6 Hop-by-Hop Option [RFC1883]1 ICMP Internet Control Message [RFC792]2 IGMP Internet Group Management [RFC1112]3 GGP Gateway-to-Gateway [RFC823]4 IP IP in IP (encapsulation) [RFC2003]5 ST Stream [RFC1190,RFC1819]6 TCP Transmission Control [RFC793]7 CBT CBT [Ballardie]8 EGP Exterior Gateway Protocol [RFC888,DLM1]9 IGP any private interior gateway [IANA](used by Cisco for their IGRP)10 BBN-RCC-MON BBN RCC Monitoring [SGC]11 NVP-II Network Voice Protocol [RFC741,SC3]12 PUP PUP [PUP,XEROX]13 ARGUS ARGUS [RWS4]14 EMCON EMCON [BN7]15 XNET Cross Net Debugger [IEN158,JFH2]16 CHAOS Chaos [NC3]17 UDP User Datagram [RFC768,JBP]18 MUX Multiplexing [IEN90,JBP]19 DCN-MEAS DCN Measurement Subsystems [DLM1]20 HMP Host Monitoring [RFC869,RH6]21 PRM Packet Radio Measurement [ZSU]22 XNS-IDP XEROX NS IDP[ETHERNET,XEROX]23 TRUNK-1 Trunk-1 [BWB6]24 TRUNK-2 Trunk-2 [BWB6]25 LEAF-1 Leaf-1 [BWB6]26 LEAF-2 Leaf-2 [BWB6]27 RDP Reliable Data Protocol [RFC908,RH6]28 IRTP Internet Reliable Transaction [RFC938,TXM]29 ISO-TP4 ISO Transport Protocol Class 4[RFC905,RC77]30 NETBLT Bulk Data Transfer Protocol[RFC969,DDC1]31 MFE-NSP MFE Network Services Protocol [MFENET,BCH2]32 MERIT-INP MERIT Internodal Protocol [HWB]33 DCCP Datagram Congestion Control Protocol34 3PC Third Party Connect Protocol [SAF3]35 IDPR Inter-Domain Policy Routing Protocol [MXS1]36 XTP XTP [GXC]37 DDP Datagram Delivery Protocol [WXC]38 IDPR-CMTP IDPR Control Message Transport Proto [MXS1]39 TP++ TP++ Transport Protocol [DXF]40 IL IL Transport Protocol [Presotto]41 IPv6 Ipv6 [Deering]42 SDRP Source Demand Routing Protocol [DXE1]43 IPv6-Route Routing Header for IPv6 [Deering]44 IPv6-Frag Fragment Header for IPv6 [Deering]45 IDRP Inter-Domain Routing Protocol [Sue Hares]46 RSVP Reservation Protocol [Bob Braden]47 GRE General Routing Encapsulation [Tony Li]48 MHRP Mobile Host Routing Protocol [David Johnson]49 BNA BNA [Gary Salamon]50 ESP Encap Security Payload [RFC2406]51 AH Authentication Header [RFC2402]52 I-NLSP Integrated Net Layer Security TUBA [GLENN]53 SWIPE IP with Encryption [JI6]54 NARP NBMA Address Resolution Protocol [RFC1735]55 MOBILE IP Mobility [Perkins]56 TLSP Transport Layer Security Protocol [Oberg] using Kryptonet key management57 SKIP SKIP [Markson]58 IPv6-ICMP ICMP for IPv6 [RFC1883]59 IPv6-NoNxt No Next Header for IPv6 [RFC1883]60 IPv6-Opts Destination Options for IPv6 [RFC1883]61 any host internal protocol [IANA]62 CFTP CFTP [CFTP,HCF2]63 any local network [IANA]64 SAT-EXPAK SATNET and Backroom EXPAK [SHB]65 KRYPTOLAN Kryptolan [PXL1]66 RVD MIT Remote Virtual Disk Protocol [MBG]67 IPPC Internet Pluribus Packet Core [SHB]68 any distributed file system [IANA]69 SAT-MON SATNET Monitoring [SHB]70 VISA VISA Protocol [GXT1]71 IPCV Internet Packet Core Utility [SHB]72 CPNX Computer Protocol Network Executive [DXM2]73 CPHB Computer Protocol Heart Beat [DXM2]74 WSN Wang Span Network [VXD]75 PVP Packet Video Protocol [SC3]76 BR-SAT-MON Backroom SATNET Monitoring [SHB]77 SUN-ND SUN ND PROTOCOL-Temporary [WM3]78 WB-MON WIDEBAND Monitoring [SHB]79 WB-EXPAK WIDEBAND EXPAK [SHB]80 ISO-IP ISO Internet Protocol [MTR]81 VMTP VMTP [DRC3]82 SECURE-VMTP SECURE-VMTP [DRC3]83 VINES VINES [BXH]84 TTP TTP [JXS]85 NSFNET-IGP NSFNET-IGP [HWB]86 DGP Dissimilar Gateway Protocol [DGP,ML109]87 TCF TCF [GAL5]88 EIGRP EIGRP [CISCO,GXS]89 OSPFIGP OSPFIGP[RFC1583,JTM4]90 Sprite-RPC Sprite RPC Protocol[SPRITE,BXW]91 LARP Locus Address Resolution Protocol [BXH]92 MTP Multicast Transport Protocol [SXA]93 AX.25 AX.25 Frames [BK29]94 IPIP IP-within-IP Encapsulation Protocol [JI6]95 MICP Mobile Internetworking Control Pro. [JI6]96 SCC-SP Semaphore Communications Sec. Pro. [HXH]97 ETHERIP Ethernet-within-IP Encapsulation[RFC3378]98 ENCAP Encapsulation Header[RFC1241,RXB3]99 any private encryption scheme [IANA]100 GMTP GMTP [RXB5]101 IFMP Ipsilon Flow Management Protocol [Hinden] 102 PNNI PNNI over IP [Callon]103 PIM Protocol Independent Multicast [Farinacci] 104 ARIS ARIS [Feldman]105 SCPS SCPS [Durst]106 QNX QNX [Hunter] 107 A/N Active Networks [Braden] 108 IPComp IP Payload Compression Protocol [RFC2393] 109 SNP Sitara Networks Protocol [Sridhar] 110 Compaq-Peer Compaq Peer Protocol [Volpe]111 IPX-in-IP IPX in IP [Lee]112 VRRP Virtual Router Redundancy Protocol [RFC3768] 113 PGM PGM Reliable Transport Protocol[Speakman]114 any 0-hop protocol [IANA]115 L2TP Layer Two Tunneling Protocol [Aboba] 116 DDX D-II Data Exchange (DDX) [Worley] 117 IATP Interactive Agent Transfer Protocol [Murphy] 118 STP Schedule Transfer Protocol [JMP]119 SRP SpectraLink Radio Protocol[Hamilton]120 UTI UTI [Lothberg] 121 SMP Simple Message Protocol [Ekblad] 122 SM SM [Crowcroft]123 PTP Performance Transparency Protocol [Welzl] 124 ISIS over IPv4 [Przygienda] 125 FIRE [Partridge]126 CRTP Combat Radio Transport Protocol [Sautter] 127 CRUDP Combat Radio User Datagram [Sautter] 128 SSCOPMCE [Waber]129 IPLT [Hollbach]130 SPS Secure Packet Shield [McIntosh] 131 PIPE Private IP Encapsulation within IP [Petri] 132 SCTP Stream Control Transmission Protocol [Stewart]133 FC Fibre Channel [Rajagopal] 134 RSVP-E2E-IGNORE [RFC3175] 135 Mobility Header [RFC3775]136 UDPLite [RFC3828] 137 MPLS-in-IP [RFC4023] 138-252Unassigned [IANA] 253 Use for experimentation and testing [RFC3692]254 Use for experimentation and testing[RFC3692]255 Reserved [IANA]相关中文解释：十进制关键字协议======= ========= ==============0 HOPOPT IPv6 逐跳选项1 ICMP Internet 控制消息2 IGMP Internet 组管理3 GGP 网关对网关4 IP IP 中的IP（封装）5 ST 流6 TCP 传输控制7 CBT CBT8 EGP 外部网关协议9 IGP 任何专用内部网关（Cisco 将其用于IGRP）10 BBN-RCC-MON BBN RCC 监视11 NVP-II 网络语音协议12 PUP PUP13 ARGUS ARGUS14 EMCON EMCON15 XNET 跨网调试器16 CHAOS Chaos17 UDP 用户数据报18 MUX 多路复用19 DCN-MEAS DCN 测量子系统20 HMP 主机监视21 PRM 数据包无线测量22 XNS-IDP XEROX NS IDP23 TRUNK-1 第1 主干24 TRUNK-2 第2 主干25 LEAF-1 第1 叶26 LEAF-2 第2 叶27 RDP 可靠数据协议28 IRTP Internet 可靠事务29 ISO-TP4 ISO 传输协议第4 类30 NETBLT 批量数据传输协议31 MFE-NSP MFE 网络服务协议32 MERIT-INP MERIT 节点间协议33 SEP 顺序交换协议34 3PC 第三方连接协议35 IDPR 域间策略路由协议36 XTP XTP37 DDP 数据报传送协议38 IDPR-CMTP IDPR 控制消息传输协议39 TP++ TP++ 传输协议40 IL IL 传输协议41 IPv6 Ipv642 SDRP 源要求路由协议43 IPv6-Route IPv6 的路由标头44 IPv6-Frag IPv6 的片断标头45 IDRP 域间路由协议46 RSVP 保留协议47 GRE 通用路由封装48 MHRP 移动主机路由协议49 BNA BNA50 ESP IPv6 的封装安全负载51 AH IPv6 的身份验证标头52 I-NLSP 集成网络层安全性TUBA53 SWIPE 采用加密的IP54 NARP NBMA 地址解析协议55 MOBILE IP 移动性56 TLSP 传输层安全协议使用Kryptonet 密钥管理57 SKIP SKIP58 IPv6-ICMP 用于IPv6 的ICMP59 IPv6-NoNxt 用于IPv6 的无下一个标头60 IPv6-Opts IPv6 的目标选项61 任意主机内部协议62 CFTP CFTP63 任意本地网络64 SAT-EXPAK SATNET 与后台EXPAK65 KRYPTOLAN Kryptolan66 RVD MIT 远程虚拟磁盘协议67 IPPC Internet Pluribus 数据包核心68 任意分布式文件系统69 SAT-MON SATNET 监视70 VISA VISA 协议71 IPCV Internet 数据包核心工具72 CPNX 计算机协议网络管理73 CPHB 计算机协议检测信号74 WSN 王安电脑网络75 PVP 数据包视频协议76 BR-SAT-MON 后台SATNET 监视77 SUN-ND SUN ND PROTOCOL-Temporary78 WB-MON WIDEBAND 监视79 WB-EXPAK WIDEBAND EXPAK80 ISO-IP ISO Internet 协议81 VMTP VMTP82 SECURE-VMTP SECURE-VMTP83 VINES VINES84 TTP TTP85 NSFNET-IGP NSFNET-IGP86 DGP 异类网关协议87 TCF TCF88 EIGRP EIGRP89 OSPFIGP OSPFIGP90 Sprite-RPC Sprite RPC 协议91 LARP 轨迹地址解析协议92 MTP 多播传输协议93 AX.25 AX.25 帧94 IPIP IP 中的IP 封装协议95 MICP 移动互联控制协议96 SCC-SP 信号通讯安全协议97 ETHERIP IP 中的以太网封装98 ENCAP 封装标头99 任意专用加密方案100 GMTP GMTP101 IFMP Ipsilon 流量管理协议102 PNNI IP 上的PNNI103 PIM 独立于协议的多播104 ARIS ARIS105 SCPS SCPS106 QNX QNX107 A/N 活动网络108 IPComp IP 负载压缩协议109 SNP Sitara 网络协议110 Compaq-Peer Compaq 对等协议111 IPX-in-IP IP 中的IPX112 VRRP 虚拟路由器冗余协议113 PGM PGM 可靠传输协议114 任意0 跳协议115 L2TP 第二层隧道协议116 DDX D-II 数据交换(DDX)117 IATP 交互式代理传输协议118 STP 计划传输协议119 SRP SpectraLink 无线协议120 UTI UTI121 SMP 简单邮件协议122 SM SM123 PTP 性能透明协议124 ISIS over IPv4125 FIRE126 CRTP Combat 无线传输协议127 CRUDP Combat 无线用户数据报128 SSCOPMCE129 IPLT130 SPS 安全数据包防护131 PIPE IP 中的专用IP 封装132 SCTP 流控制传输协议133 FC 光纤通道134-254 未分配255 保留常识Protocol ID：十进制关键字协议。
ICMPv6 RFC changes
Token-bucket based method.
- Added specification that all ICMP error messages shall have exactly
- Removed references to RFC-1112 in Abstract, and Section 1, and to
RFC-1191 in section 1, and section 3.2
- Added security section
- Added Appendix A - changes
- Replaced word "send" with "originate" to make it clear that ICMP
packets being forwarded are out of scope of this specification.
- Changed the ESP and AH references to the updated ESP and AH
specification.
- Removed rate control from informational messages.
- Added requirement that receivers ignore Code value in Packet Too
Big message.
- Removed section 2.4 on Group Management ICMP messages
rfc5288.AES Galois Counter Mode (GCM) Cipher Suites for TLS
Network Working Group J. Salowey Request for Comments: 5288 A. Choudhury Category: Standards Track D. McGrew Cisco Systems, Inc. August 2008 AES Galois Counter Mode (GCM) Cipher Suites for TLSStatus of This MemoThis document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions forimprovements. Please refer to the current edition of the "InternetOfficial Protocol Standards" (STD 1) for the standardization stateand status of this protocol. Distribution of this memo is unlimited.AbstractThis memo describes the use of the Advanced Encryption Standard (AES) in Galois/Counter Mode (GCM) as a Transport Layer Security (TLS)authenticated encryption operation. GCM provides bothconfidentiality and data origin authentication, can be efficientlyimplemented in hardware for speeds of 10 gigabits per second andabove, and is also well-suited to software implementations. Thismemo defines TLS cipher suites that use AES-GCM with RSA, DSA, andDiffie-Hellman-based key exchange mechanisms.Table of Contents1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 22. Conventions Used in This Document . . . . . . . . . . . . . . . 23. AES-GCM Cipher Suites . . . . . . . . . . . . . . . . . . . . . 24. TLS Versions . . . . . . . . . . . . . . . . . . . . . . . . . 35. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 46. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 6.1. Counter Reuse . . . . . . . . . . . . . . . . . . . . . . . 46.2. Recommendations for Multiple Encryption Processors . . . . 47. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 58. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 8.1. Normative References . . . . . . . . . . . . . . . . . . . 6 8.2. Informative References . . . . . . . . . . . . . . . . . . 6 Salowey, et al. Standards Track [Page 1]1. IntroductionThis document describes the use of AES [AES] in Galois Counter Mode(GCM) [GCM] (AES-GCM) with various key exchange mechanisms as acipher suite for TLS. AES-GCM is an authenticated encryption withassociated data (AEAD) cipher (as defined in TLS 1.2 [RFC5246])providing both confidentiality and data origin authentication. Thefollowing sections define cipher suites based on RSA, DSA, andDiffie-Hellman key exchanges; ECC-based (Elliptic Curve Cryptography) cipher suites are defined in a separate document [RFC5289].AES-GCM is not only efficient and secure, but hardwareimplementations can achieve high speeds with low cost and lowlatency, because the mode can be pipelined. Applications thatrequire high data throughput can benefit from these high-speedimplementations. AES-GCM has been specified as a mode that can beused with IPsec ESP [RFC4106] and 802.1AE Media Access Control (MAC) Security [IEEE8021AE].2. Conventions Used in This DocumentThe key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].3. AES-GCM Cipher SuitesThe following cipher suites use the new authenticated encryptionmodes defined in TLS 1.2 with AES in Galois Counter Mode (GCM) [GCM]: CipherSuite TLS_RSA_WITH_AES_128_GCM_SHA256 = {0x00,0x9C}CipherSuite TLS_RSA_WITH_AES_256_GCM_SHA384 = {0x00,0x9D}CipherSuite TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 = {0x00,0x9E}CipherSuite TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 = {0x00,0x9F}CipherSuite TLS_DH_RSA_WITH_AES_128_GCM_SHA256 = {0x00,0xA0}CipherSuite TLS_DH_RSA_WITH_AES_256_GCM_SHA384 = {0x00,0xA1}CipherSuite TLS_DHE_DSS_WITH_AES_128_GCM_SHA256 = {0x00,0xA2}CipherSuite TLS_DHE_DSS_WITH_AES_256_GCM_SHA384 = {0x00,0xA3}CipherSuite TLS_DH_DSS_WITH_AES_128_GCM_SHA256 = {0x00,0xA4}CipherSuite TLS_DH_DSS_WITH_AES_256_GCM_SHA384 = {0x00,0xA5}CipherSuite TLS_DH_anon_WITH_AES_128_GCM_SHA256 = {0x00,0xA6}CipherSuite TLS_DH_anon_WITH_AES_256_GCM_SHA384 = {0x00,0xA7}These cipher suites use the AES-GCM authenticated encryption withassociated data (AEAD) algorithms AEAD_AES_128_GCM andAEAD_AES_256_GCM described in [RFC5116]. Note that each of theseAEAD algorithms uses a 128-bit authentication tag with GCM (inparticular, as described in Section 3.5 of [RFC4366], theSalowey, et al. Standards Track [Page 2]"truncated_hmac" extension does not have an effect on cipher suitesthat do not use HMAC). The "nonce" SHALL be 12 bytes long consisting of two parts as follows: (this is an example of a "partiallyexplicit" nonce; see Section 3.2.1 in [RFC5116]).struct {opaque salt[4];opaque nonce_explicit[8];} GCMNonce;The salt is the "implicit" part of the nonce and is not sent in thepacket. Instead, the salt is generated as part of the handshakeprocess: it is either the client_write_IV (when the client issending) or the server_write_IV (when the server is sending). Thesalt length (SecurityParameters.fixed_iv_length) is 4 octets.The nonce_explicit is the "explicit" part of the nonce. It is chosen by the sender and is carried in each TLS record in theGenericAEADCipher.nonce_explicit field. The nonce_explicit length(SecurityParameters.record_iv_length) is 8 octets.Each value of the nonce_explicit MUST be distinct for each distinctinvocation of the GCM encrypt function for any fixed key. Failure to meet this uniqueness requirement can significantly degrade security. The nonce_explicit MAY be the 64-bit sequence number.The RSA, DHE_RSA, DH_RSA, DHE_DSS, DH_DSS, and DH_anon key exchanges are performed as defined in [RFC5246].The Pseudo Random Function (PRF) algorithms SHALL be as follows:For cipher suites ending with _SHA256, the PRF is the TLS PRF[RFC5246] with SHA-256 as the hash function.For cipher suites ending with _SHA384, the PRF is the TLS PRF[RFC5246] with SHA-384 as the hash function.Implementations MUST send TLS Alert bad_record_mac for all types offailures encountered in processing the AES-GCM algorithm.4. TLS VersionsThese cipher suites make use of the authenticated encryption withadditional data defined in TLS 1.2 [RFC5246]. They MUST NOT benegotiated in older versions of TLS. Clients MUST NOT offer thesecipher suites if they do not offer TLS 1.2 or later. Servers thatselect an earlier version of TLS MUST NOT select one of these cipher suites. Because TLS has no way for the client to indicate that it Salowey, et al. Standards Track [Page 3]supports TLS 1.2 but not earlier, a non-compliant server mightpotentially negotiate TLS 1.1 or earlier and select one of the cipher suites in this document. Clients MUST check the TLS version andgenerate a fatal "illegal_parameter" alert if they detect anincorrect version.5. IANA ConsiderationsIANA has assigned the following values for the cipher suites defined in this document:CipherSuite TLS_RSA_WITH_AES_128_GCM_SHA256 = {0x00,0x9C}CipherSuite TLS_RSA_WITH_AES_256_GCM_SHA384 = {0x00,0x9D}CipherSuite TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 = {0x00,0x9E}CipherSuite TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 = {0x00,0x9F}CipherSuite TLS_DH_RSA_WITH_AES_128_GCM_SHA256 = {0x00,0xA0}CipherSuite TLS_DH_RSA_WITH_AES_256_GCM_SHA384 = {0x00,0xA1}CipherSuite TLS_DHE_DSS_WITH_AES_128_GCM_SHA256 = {0x00,0xA2}CipherSuite TLS_DHE_DSS_WITH_AES_256_GCM_SHA384 = {0x00,0xA3}CipherSuite TLS_DH_DSS_WITH_AES_128_GCM_SHA256 = {0x00,0xA4}CipherSuite TLS_DH_DSS_WITH_AES_256_GCM_SHA384 = {0x00,0xA5}CipherSuite TLS_DH_anon_WITH_AES_128_GCM_SHA256 = {0x00,0xA6}CipherSuite TLS_DH_anon_WITH_AES_256_GCM_SHA384 = {0x00,0xA7}6. Security ConsiderationsThe security considerations in [RFC5246] apply to this document aswell. The remainder of this section describes securityconsiderations specific to the cipher suites described in thisdocument.6.1. Counter ReuseAES-GCM security requires that the counter is never reused. The IVconstruction in Section 3 is designed to prevent counter reuse.Implementers should also understand the practical considerations ofIV handling outlined in Section 9 of [GCM].6.2. Recommendations for Multiple Encryption ProcessorsIf multiple cryptographic processors are in use by the sender, thenthe sender MUST ensure that, for a particular key, each value of the nonce_explicit used with that key is distinct. In this case, eachencryption processor SHOULD include, in the nonce_explicit, a fixedvalue that is distinct for each processor. The recommended format is nonce_explicit = FixedDistinct || VariableSalowey, et al. Standards Track [Page 4]where the FixedDistinct field is distinct for each encryptionprocessor, but is fixed for a given processor, and the Variable field is distinct for each distinct nonce used by a particular encryptionprocessor. When this method is used, the FixedDistinct fields usedby the different processors MUST have the same length.In the terms of Figure 2 in [RFC5116], the Salt is the Fixed-Commonpart of the nonce (it is fixed, and it is common across allencryption processors), the FixedDistinct field exactly correspondsto the Fixed-Distinct field, the Variable field corresponds to theCounter field, and the explicit part exactly corresponds to thenonce_explicit.For clarity, we provide an example for TLS in which there are twodistinct encryption processors, each of which uses a one-byteFixedDistinct field:Salt = eedc68dcFixedDistinct = 01 (for the first encryption processor) FixedDistinct = 02 (for the second encryption processor)The GCMnonces generated by the first encryption processor, and their corresponding nonce_explicit, are:GCMNonce nonce_explicit------------------------ ----------------------------eedc68dc0100000000000000 0100000000000000eedc68dc0100000000000001 0100000000000001eedc68dc0100000000000002 0100000000000002...The GCMnonces generated by the second encryption processor, and their corresponding nonce_explicit, areGCMNonce nonce_explicit------------------------ ----------------------------eedc68dc0200000000000000 0200000000000000eedc68dc0200000000000001 0200000000000001eedc68dc0200000000000002 0200000000000002...7. AcknowledgementsThis document borrows heavily from [RFC5289]. The authors would like to thank Alex Lam, Simon Josefsson, and Pasi Eronen for providinguseful comments during the review of this document.Salowey, et al. Standards Track [Page 5]8. References8.1. Normative References[AES] National Institute of Standards and Technology,"Advanced Encryption Standard (AES)", FIPS 197,November 2001.[GCM] Dworkin, M., "Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC",National Institute of Standards and Technology SP 800- 38D, November 2007.[RFC2119] Bradner, S., "Key words for use in RFCs to IndicateRequirement Levels", BCP 14, RFC 2119, March 1997.[RFC5116] McGrew, D., "An Interface and Algorithms forAuthenticated Encryption", RFC 5116, January 2008.[RFC5246] Dierks, T. and E. Rescorla, "The Transport LayerSecurity (TLS) Protocol Version 1.2", RFC 5246,August 2008.8.2. Informative References[IEEE8021AE] Institute of Electrical and Electronics Engineers,"Media Access Control Security", IEEE Standard 802.1AE, August 2006.[RFC4106] Viega, J. and D. McGrew, "The Use of Galois/CounterMode (GCM) in IPsec Encapsulating Security Payload(ESP)", RFC 4106, June 2005.[RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and T. Wright, "Transport Layer Security (TLS)Extensions", RFC 4366, April 2006.[RFC5289] Rescorla, E., "TLS Elliptic Curve Cipher Suites withSHA-256/384 and AES Galois Counter Mode", RFC 5289,August 2008.Salowey, et al. Standards Track [Page 6]Authors’ AddressesJoseph SaloweyCisco Systems, Inc.2901 3rd. AveSeattle, WA 98121USAEMail: jsalowey@Abhijit ChoudhuryCisco Systems, Inc.3625 Cisco WaySan Jose, CA 95134USAEMail: abhijitc@David McGrewCisco Systems, Inc.170 W Tasman DriveSan Jose, CA 95134USAEMail: mcgrew@Salowey, et al. Standards Track [Page 7]Full Copyright StatementCopyright (C) The IETF Trust (2008).This document is subject to the rights, licenses and restrictionscontained in BCP 78, and except as set forth therein, the authorsretain all their rights.This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIEDWARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual PropertyThe IETF takes no position regarding the validity or scope of anyIntellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described inthis document or the extent to which any license under such rightsmight or might not be available; nor does it represent that it hasmade any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can befound in BCP 78 and BCP 79.Copies of IPR disclosures made to the IETF Secretariat and anyassurances of licenses to be made available, or the result of anattempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of thisspecification can be obtained from the IETF on-line IPR repository at /ipr.The IETF invites any interested party to bring to its attention anycopyrights, patents or patent applications, or other proprietaryrights that may cover technology that may be required to implementthis standard. Please address the information to the IETF atietf-ipr@.Salowey, et al. Standards Track [Page 8]。
ip协议号大全
ip协议号⼤全ip协议号⼤全PROTOCOL NUMBERS(last updated 08 September 2005)In the Internet Protocol version 4 (IPv4) [RFC791] there is a field,called "Protocol", to identify the next level protocol. This is an 8bit field. In Internet Protocol version 6 (IPv6) [RFC1883] this fieldis called the "Next Header" field.Assigned Internet Protocol NumbersDecimal Keyword Protocol References------- ------- -------- ----------0 HOPOPT IPv6 Hop-by-Hop Option [RFC1883]1 ICMP Internet Control Message [RFC792]2 IGMP Internet Group Management [RFC1112]3 GGP Gateway-to-Gateway [RFC823]4 IP IP in IP (encapsulation) [RFC2003]5 ST Stream [RFC1190,RFC1819]6 TCP Transmission Control [RFC793]7 CBT CBT [Ballardie]8 EGP Exterior Gateway Protocol [RFC888,DLM1]9 IGP any private interior gateway [IANA](used by Cisco for their IGRP)10 BBN-RCC-MON BBN RCC Monitoring [SGC]11 NVP-II Network Voice Protocol [RFC741,SC3]12 PUP PUP [PUP,XEROX]13 ARGUS ARGUS [RWS4]14 EMCON EMCON [BN7]15 XNET Cross Net Debugger [IEN158,JFH2]16 CHAOS Chaos [NC3]17 UDP User Datagram [RFC768,JBP]18 MUX Multiplexing [IEN90,JBP]19 DCN-MEAS DCN Measurement Subsystems [DLM1]20 HMP Host Monitoring [RFC869,RH6]21 PRM Packet Radio Measurement [ZSU]22 XNS-IDP XEROX NS IDP [ETHERNET,XEROX]23 TRUNK-1 Trunk-1 [BWB6]24 TRUNK-2 Trunk-2 [BWB6]25 LEAF-1 Leaf-1 [BWB6]26 LEAF-2 Leaf-2 [BWB6]27 RDP Reliable Data Protocol [RFC908,RH6]28 IRTP Internet Reliable Transaction [RFC938,TXM]29 ISO-TP4 ISO Transport Protocol Class 4 [RFC905,RC77]30 NETBLT Bulk Data Transfer Protocol [RFC969,DDC1]31 MFE-NSP MFE Network Services Protocol [MFENET,BCH2]32 MERIT-INP MERIT Internodal Protocol [HWB]33 DCCP Datagram Congestion Control Protocol [RFC-ietf-dccp-spec-11.txt]34 3PC Third Party Connect Protocol [SAF3]35 IDPR Inter-Domain Policy Routing Protocol [MXS1]36 XTP XTP [GXC]37 DDP Datagram Delivery Protocol [WXC]38 IDPR-CMTP IDPR Control Message Transport Proto [MXS1]39 TP++ TP++ Transport Protocol [DXF]40 IL IL Transport Protocol [Presotto]41 IPv6 Ipv6 [Deering]42 SDRP Source Demand Routing Protocol [DXE1]43 IPv6-Route Routing Header for IPv6 [Deering]44 IPv6-Frag Fragment Header for IPv6 [Deering]45 IDRP Inter-Domain Routing Protocol [Sue Hares]46 RSVP Reservation Protocol [Bob Braden]47 GRE General Routing Encapsulation [Tony Li]48 MHRP Mobile Host Routing Protocol[David Johnson]49 BNA BNA [Gary Salamon]50 ESP Encap Security Payload [RFC2406]51 AH Authentication Header [RFC2402]52 I-NLSP Integrated Net Layer Security TUBA [GLENN]53 SWIPE IP with Encryption [JI6]54 NARP NBMA Address Resolution Protocol [RFC1735]55 MOBILE IP Mobility [Perkins]56 TLSP Transport Layer Security Protocol [Oberg]using Kryptonet key management57 SKIP SKIP [Markson]58 IPv6-ICMP ICMP for IPv6 [RFC1883]59 IPv6-NoNxt No Next Header for IPv6 [RFC1883]60 IPv6-Opts Destination Options for IPv6 [RFC1883]61 any host internal protocol [IANA]62 CFTP CFTP [CFTP,HCF2]63 any local network [IANA]64 SAT-EXPAK SATNET and Backroom EXPAK [SHB]65 KRYPTOLAN Kryptolan [PXL1]66 RVD MIT Remote Virtual Disk Protocol [MBG]67 IPPC Internet Pluribus Packet Core [SHB]68 any distributed file system [IANA]69 SAT-MON SATNET Monitoring [SHB]70 VISA VISA Protocol [GXT1]71 IPCV Internet Packet Core Utility [SHB]72 CPNX Computer Protocol Network Executive [DXM2]73 CPHB Computer Protocol Heart Beat [DXM2]74 WSN Wang Span Network [VXD]75 PVP Packet Video Protocol [SC3]76 BR-SAT-MON Backroom SATNET Monitoring [SHB]77 SUN-ND SUN ND PROTOCOL-Temporary [WM3]78 WB-MON WIDEBAND Monitoring [SHB]79 WB-EXPAK WIDEBAND EXPAK [SHB]80 ISO-IP ISO Internet Protocol [MTR]81 VMTP VMTP [DRC3]82 SECURE-VMTP SECURE-VMTP [DRC3]83 VINES VINES [BXH]84 TTP TTP [JXS]85 NSFNET-IGP NSFNET-IGP [HWB]86 DGP Dissimilar Gateway Protocol [DGP,ML109]87 TCF TCF [GAL5]88 EIGRP EIGRP [CISCO,GXS]89 OSPFIGP OSPFIGP [RFC1583,JTM4]90 Sprite-RPC Sprite RPC Protocol [SPRITE,BXW]91 LARP Locus Address Resolution Protocol [BXH]92 MTP Multicast Transport Protocol [SXA]93 AX.25 AX.25 Frames [BK29]94 IPIP IP-within-IP Encapsulation Protocol [JI6]95 MICP Mobile Internetworking Control Pro. [JI6]96 SCC-SP Semaphore Communications Sec. Pro. [HXH]97 ETHERIP Ethernet-within-IP Encapsulation [RFC3378]98 ENCAP Encapsulation Header [RFC1241,RXB3]99 any private encryption scheme [IANA]100 GMTP GMTP [RXB5]101 IFMP Ipsilon Flow Management Protocol [Hinden] 102 PNNI PNNI over IP [Callon]103 PIM Protocol Independent Multicast [Farinacci]104 ARIS ARIS [Feldman]105 SCPS SCPS [Durst]106 QNX QNX [Hunter]107 A/N Active Networks [Braden]108 IPComp IP Payload Compression Protocol [RFC2393] 109 SNP Sitara Networks Protocol [Sridhar]110 Compaq-Peer Compaq Peer Protocol [Volpe]111 IPX-in-IP IPX in IP [Lee]112 VRRP Virtual Router Redundancy Protocol [RFC3768] 113 PGM PGM Reliable Transport Protocol [Speakman] 114 any 0-hop protocol [IANA]115 L2TP Layer Two Tunneling Protocol [Aboba]116 DDX D-II Data Exchange (DDX) [Worley]117 IATP Interactive Agent Transfer Protocol [Murphy] 118 STP Schedule Transfer Protocol [JMP]119 SRP SpectraLink Radio Protocol [Hamilton]120 UTI UTI [Lothberg]121 SMP Simple Message Protocol [Ekblad]122 SM SM [Crowcroft]123 PTP Performance Transparency Protocol [Welzl]124 ISIS over IPv4 [Przygienda]125 FIRE [Partridge]126 CRTP Combat Radio Transport Protocol [Sautter] 127 CRUDP Combat Radio User Datagram [Sautter]128 SSCOPMCE [Waber]129 IPLT [Hollbach]130 SPS Secure Packet Shield [McIntosh]131 PIPE Private IP Encapsulation within IP [Petri]132 SCTP Stream Control Transmission Protocol [Stewart] 133 FC Fibre Channel [Rajagopal]134 RSVP-E2E-IGNORE [RFC3175]135 Mobility Header [RFC3775]136 UDPLite [RFC3828]137 MPLS-in-IP [RFC4023]138-252 Unassigned [IANA]253 Use for experimentation and testing [RFC3692]254 Use for experimentation and testing [RFC3692]255 Reserved [IANA。
rfc3358.Optional Checksums in Intermediate System to Intermediate System (ISIS)
Network Working Group T. Przygienda Request for Comments: 3358 Xebeo Category: Informational August 2002 Optional Checksums inIntermediate System to Intermediate System (ISIS)Status 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) The Internet Society (2002). All Rights Reserved. AbstractThis document describes an optional extension to the IntermediateSystem to Intermediate System (ISIS) protocol, used today by several Internet Service Proviers (ISPs) for routing within their clouds.ISIS is an interior gateway routing protocol developed originally by OSI and used with IP extensions as Interior Gateway Protocol (IGP).ISIS originally does not provide Complete Sequence Numbers ProtocolData (CSNP) and Partial Sequence Numbers Protocol Data Unit (PSNP)checksums, relying on the underlying layers to verify the integrityof information provided. Experience with the protocol shows thatthis precondition does not always hold and scenarios can be imagined that impact protocol functionality. This document introduces a newoptional Type, Length and Value (TLV) providing checksums.1. IntroductionISIS [ISO90, Cal90a, Cal90b] CSNPs and PSNPs and IIHs can becorrupted in case of faulty implementations of L2 hardware or lack of checksuming on a specific network technology. As a particularly ugly case, corruption of length and/or TLV length fields may lead to thegeneration of extensive numbers of "empty" LSPs in the receivingnode. Since we cannot rely on authentication as a checksummechanism, this document proposes an optional TLV to add checksums to the elements.The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [Bra97].Przygienda Informational [Page 1]2. TLV DescriptionThis optional TLV MAY BE included in all CSNP, PSNP and IIH packetsand an implementation that implements optional checksums MUST accept PDUs if they do NOT contain the optional checksum. Implementationsthat receive an optional checksum TLV and support it MUST discard the PDU if the checksum is incorrect. An implementation that does NOTimplement optional checksums MUST accept a PDU that contains thechecksum TLV. An implementation that supports optional checksums and receives it within any other PDU than CSNP, PSNP or IIH MUST discard the PDU. Such an implementation MUST discard the PDU as well if more than one optional checksum TLVs are included within it.Additionally, any implementation supporting optional checksums MUSTaccept PDUs with an optional checksum with the value 0 and considersuch a checksum as correct.3. Checksum ComputationThe checksum is a fletcher checksum computed according to [ISO98],Annex C over the complete PDU. To compute the correct checksum, animplementation MUST add the optional checksum TLV to the PDU with the initial checksum value of 0 and compute the checksum over such a PDU.4. Interaction with TLVs using PDU Data to Compute SignaturesThe implementation MUST either omit the optional checksum on aninterface or send a 0 checksum value if it includes in the PDUsignatures that provide equivalent or stronger functionality, such as HMAC or MD5. Otherwise an implementation that handles suchsignatures but does not handle the optional checksums, may fail tocompute the MD5 signature on the packet. Such a failure would becaused by the fact that MD5 is computed with the checksum value setto 0 and only as a final step is the checksum value being filled in.5. TLV Format[Prz01] lists the according value of the TLV type and discussesissues surrounding the assignment of new TLV codepoints.0 1 2 30 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| TLV Type =12 | TLV Length =2 | Checksum (16 bits) |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Przygienda Informational [Page 2]6. AcknowledgmentsTony Li mentioned the original problem. Mike Shand providedcomments. Somehow related problems with purging on LSP checksumerrors have been observed by others before. Nischal Sheth spelledout the issues of interaction between MD5 and the optional checksums.7. Security ConsiderationsISIS security applies to the work presented. No specific securityissues as to the new element are known.References[Bra97] Bradner, S., "Key Words for Use in RFCs to IndicateRequirement Levels", BCP 14, RFC 2119, March 1997.[Cal90a] Callon, R., "OSI ISIS Intradomain Routing Protocol", RFC1142, February 1990.[Cal90b] Callon, R., "Use of OSI ISIS for Routing in TCP/IP and Dual Environments", RFC 1195, December 1990.[ISO90] ISO. Information Technology - Telecommunications andInformation Exchange between Systems - Intermediate Systemto Intermediate System Routing Exchange Protocol for Use in Conjunction with the Protocol for Providing theConnectionless-Mode Network Service. ISO, 1990.[ISO98] ISO. Information Technology - Protocol for Providing theConnectionless-Mode Network Service: ProtocolSpecification. ISO, 1998.[Prz01] Przygienda, T., "Reserved Type, Length and Value (TLV)Codepoints in Intermediate System to Intermediate System",RFC 3359, August 2002.Author’s AddressTony PrzygiendaXebeoOne Cragwood RoadSouth Plainfield, NJ 07080Phone: (908) 222 4225Email: prz@Przygienda Informational [Page 3]Full Copyright StatementCopyright (C) The Internet Society (2002). All Rights Reserved.This document and translations of it may be copied and furnished toothers, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, publishedand distributed, in whole or in part, without restriction of anykind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, thisdocument itself may not be modified in any way, such as by removingthe copyright notice or references to the Internet Society or otherInternet organizations, except as needed for the purpose ofdeveloping Internet standards in which case the procedures forcopyrights defined in the Internet Standards process must befollowed, or as required to translate it into languages other thanEnglish.The limited permissions granted above are perpetual and will not berevoked by the Internet Society or its successors or assigns.This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERINGTASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDINGBUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATIONHEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OFMERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.AcknowledgementFunding for the RFC Editor function is currently provided by theInternet Society.Przygienda Informational [Page 4]。
IPV4&VLAN&NAT
Total Length─ 指定整个 IP 数据包的字节长度，包括数据和协议头。
其最大值为65,535字节。
典型的主机可以接收576字节的数据报。
Identification─ 包含一个整数，用于识别当前数据报。
该字段由发送端分配帮助接收端集中数据报分片。
Flags─ 由3位字段构成，其中低两位（最不重要）控制分片。
低位指出数据包是否可进行分片。
中间位指出在一系列分片数据包中数据包是否是最后的分片。
第三位即最高位不使用。
Fragment Offset─ 13位字段，指出与源数据报的起始端相关的分片数据位置，支持目标IP适当重建源数据报。
Time-to-Live─ 是一种计数器，在丢弃数据报的每个点值依次减1直至减少为0。
这样确保数据包无止境的环路过程。
Protocol─ 指出在 IP 处理过程完成之后，有哪种上层协议接收导入数据包。
Header Checksum─ 帮助确保 IP 协议头的完整性。
由于某些协议头字段的改变，如生存期（Time to Live），这就需要对每个点重新计算和检验。
Internet 协议头需要进行处理。
Source Address─ 指定发送代码。
Destination Address─ 指定接收代码。
Options─ 允许 IP 支持各种选项，如安全性。
Data─ 包括上层信息。
编辑本段发展目前基于IPv4的网络难以实现网络实名制，一个重要原因就是因为IP资源的共用，因为IP资源不够，所以不同的人在不同的时间段共用一个IP，IP和上网用户无法实现一一对应。
而IPv6的普及将改变现状，因为IPv6一个重要的应用将是实现网络实名制下的互联网身份证/VIeID，在IPv4下，现在根据IP查人也比较麻烦，电信局要保留一段时间的上网日志才行，通常因为数据量很大，运营商只保留三个月左右的上网日志，比如查前年某个IP发帖子的用户就不能实现。
IPv6的出现可以从技术上一劳永逸地解决实名制这个问题，因为那时IP资源将不再紧张，运营商有足够多的IP资源，那时候，运营商在受理入网申请的时候，可以直接给该用户分配一个固定IP地址，这样实际就实现了实名制，也就是一个真实用户和一个IP地址的一一对应。
络原理涉及的概念
Fool’s day RFC
1999 D. Waitzman (1 April 1999). IP over Avian Carriers with Quality of Service. IETF. RFC 2549. Updates RFC 1149, listed above. (see IP over Avian Carriers) S. Glassman, M. Manasse, J. Mogul (1 April 1999). Y10K and Beyond. IETF. RFC 2550. S. Bradner (1 April 1999). The Roman Standards Process -- Revision III. IETF. RFC 2551. 2000 S. Christey (1 April 2000). The Infinite Monkey Protocol Suite (IMPS). IETF. RFC 2795. Concerning the practicalities of the infinite monkey theorem. 2001 H. Kennedy (1 April 2001). Pi Digit Generation Protocol. IETF. RFC 3091. D. Eastlake 3rd, C. Manros, E. Raymond (1 April 2001). Etymology of "Foo". IETF. RFC 3092. M. Gaynor, S. Bradner (1 April 2001). Firewall Enhancement Protocol (FEP). IETF. RFC 3093. 2002 B. Rajagopalan (1 April 2002). Electricity over IP. IETF. RFC 3251. H. Kennedy (1 April 2002). Binary Lexical Octet Ad-hoc T ransport. IETF. RFC 3252.
计算机网络，HTTP-头部中带X前缀的头部字段
计算机⽹络，HTTP-头部中带X前缀的头部字段HTTP中，什么是"X-" Prefix header?例如的response headers有很多X前缀的头部:查⼀下:Custom proprietary headers have historically been used with an X- prefix, but this convention was deprecated in June 2012 because of the inconveniences it caused when nonstandard fields became standard in RFC 6648; others are listed in an IANA registry, whose original content was defined in RFC 4229.IANA also maintains a registry of proposed new HTTP headers.原来是⾃定义头部。
但是上⾯⽂档说，已经deprecated，过时了。
作⽤和HTTP headers⼀样，都是提供额外的信息。
Their main purpose is for providing additional information表明X前缀的⾃定义头已经过时了，代替解决⽅案是什么？根据，推荐继续保留:Although the recommendation to use X- has been deprecated, it doesn’t mean that it is no longer supported. In fact, there are still many scenarios where X-continues to be used.根据，推荐继续保留：Just as there are many kids that will never end up as professional athletes, many custom headers will never end up as standards. I'm inclined to keep the "X-"on thoseIf you're using custom HTTP Headers (as a sometimes-appropriate alternative to cookies) within your app to pass data to/from your server, and theseheaders are, explicitly, NOT intended ever to be used outside the context of your application, name-spacing them with an "X-" or "X-FOO-" prefix is areasonable, and common, convention.总结虽然RFC已经不推荐使⽤带X前缀的http 头部，但是不推荐不代表禁⽌。
RFC2326中文版
1 绪论1.1 目的实时流协议（RTSP）建立并控制一个或几个时间同步的连续流媒体。
尽管连续媒体流与控制流有可能交叉，但RTSP 本身通常并不发送连续媒体流。
换言之，RTSP充当多媒体服务器的网络远程控制。
表示描述(presentation description)定义了被控流，但本文并没有定义表示描述的格式。
这里没有使用RTSP连接的概念，而由RTSP会话(session)代替（每次服务由服务器端保持一个带标签的会话）。
RTSP会话没有绑定到传输层连接（如TCP连接）。
因为虽然在RTSP会话期间，RTSP客户端可打开或关闭多个对服务器端的可靠传输连接以发出RTSP 请求。
但此外，也可能使用无连接传输协议，比如用UDP发送RTSP请求。
RTSP控制的流可能用到RTP，但RTSP操作并不依赖用于携带连续媒体的传输机制。
实时流协议在语法和操作上与HTTP/1.1类似，因此HTTP的扩展机制大都可加入RTSP。
尽管如此，RTSP在很多方面还是和HTTP有很大的不同：2 RTSP引入了很多新方法并且有不同的协议标识符。
2 RTSP服务器在大多数默认情况下需要维持一个状态，但HTTP是无状态协议。
2 RTSP客户机和服务器都可以发出请求。
2 数据由另一个协议传送（有一特例除外）。
2 RTSP使用ISO 10646(UTF-8) 而不是ISO 8859-1，以配合当前HTML的国际化。
2 RTSP使用URI请求时包含绝对URI。
而由于历史原因造成的向后兼容性问题，HTTP/1.1只在请求中包含绝对路径，把主机名放入单独的标题域中。
这使得“虚拟主机”实现更为简便，一个单独IP地址的主机可虚拟为几个文件树主机。
协议支持的操作如下：从媒体服务器上检索媒体：用户可通过HTTP或其它方法请求一个表示描述。
如表示是组播，表示描述就包含用于连续媒体的的组播地址和端口。
如表示仅通过单播发送给用户，用户为了安全应提供目的地址。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
Network Working Group B. Fenner Request for Comments: 3228 AT&T Research BCP: 57 February 2002 Category: Best Current PracticeIANA Considerations forIPv4 Internet Group Management Protocol (IGMP)Status of this MemoThis document specifies an Internet Best Current Practices for theInternet Community, and requests discussion and suggestions forimprovements. Distribution of this memo is unlimited.Copyright NoticeCopyright (C) The Internet Society (2002). All Rights Reserved. AbstractThis memo requests that the IANA create a registry for fields in the IGMP (Internet Group Management Protocol) protocol header, andprovides guidance for the IANA to use in assigning parameters forthose fields.Table of Contents1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 12. IANA Considerations for fields in the IPv4 IGMP header. . . . 23. Assignments for testing and experimentation . . . . . . . . . 24. Security Considerations . . . . . . . . . . . . . . . . . . . 25. Normative References. . . . . . . . . . . . . . . . . . . . . 26. Informative References. . . . . . . . . . . . . . . . . . . . 37. Author’s Address. . . . . . . . . . . . . . . . . . . . . . . 38. Full Copyright Statement. . . . . . . . . . . . . . . . . . . 4 1. IntroductionThis memo requests that the IANA create a registry for fields in the IGMP protocol header.The terms "Specification Required", "Expert Review", "IESG Approval", "IETF Consensus", and "Standards Action", are used in this memo torefer to the processes described in [2].Fenner Best Current Practice [Page 1]2. IANA Considerations for fields in the IPv4 IGMP headerThe IPv4 IGMP header [1] contains the following fields that carryvalues assigned from IANA-managed name spaces: Type and Code. Codefield values are defined relative to a specific Type value.Values for the IPv4 IGMP Type fields are allocated using an IESGApproval or Standards Action processes. Code Values for existingIPv4 IGMP Type fields are allocated using IESG Approval or Standards Action processes. The policy for assigning Code values for new IPv4 IGMP Types should be defined in the document defining the new Typevalue.3. Assignments for testing and experimentationInstead of suggesting temporary assignments as in [3], this document follows the lead of [4] and assigns a range of values forexperimental use. The IGMP Code values 240-255 inclusive (0xf0 -0xff) are reserved for protocol testing and experimentation.Systems should silently ignore IGMP messages with unknown Codevalues.4. Security ConsiderationsSecurity analyzers such as firewalls and network intrusion detection monitors often rely on unambiguous interpretations of the fieldsdescribed in this memo. As new values for the fields are assigned,existing security analyzers that do not understand the new values may fail, resulting in either loss of connectivity if the analyzerdeclines to forward the unrecognized traffic, or loss of security if it does forward the traffic and the new values are used as part of an attack. This vulnerability argues for high visibility (which theStandards Action and IETF Consensus processes ensure) for theassignments whenever possible.5. Normative References[1] Fenner, W., "Internet Group Management Protocol, Version 2",RFC 2236, November 1997.[2] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANAConsiderations Section in RFCs", BCP 26, RFC 2434, October1998.Fenner Best Current Practice [Page 2]6. Informative References[3] Bradner, S. and V. Paxson, "IANA Allocation Guidelines ForValues In the Internet Protocol and Related Headers", BCP 37,RFC 2780, March 2000.[4] Narten, T., "Assigning Experimental and Testing NumbersConsidered Useful", Work in Progress.7. Author’s AddressBill FennerAT&T Labs -- Research75 Willow RdMenlo Park, CA 94025USAEMail: fenner@Fenner Best Current Practice [Page 3]8. Full Copyright StatementCopyright (C) The Internet Society (2002). All Rights Reserved.This document and translations of it may be copied and furnished toothers, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, publishedand distributed, in whole or in part, without restriction of anykind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, thisdocument itself may not be modified in any way, such as by removingthe copyright notice or references to the Internet Society or otherInternet organizations, except as needed for the purpose ofdeveloping Internet standards in which case the procedures forcopyrights defined in the Internet Standards process must befollowed, or as required to translate it into languages other thanEnglish.The limited permissions granted above are perpetual and will not berevoked by the Internet Society or its successors or assigns.This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERINGTASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDINGBUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATIONHEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OFMERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.AcknowledgementFunding for the RFC Editor function is currently provided by theInternet Society.Fenner Best Current Practice [Page 4]。