RFC2053

合集下载

RFC文档阅读 1-100

RFC974_邮件路由与域名系统
RFC975_自治联邦
RFC976 UUCP 邮件互换格式标准
RFC985 Internet 网关要求 - 起草
RFC988 主机扩展用于IP多点传送
RFC文档阅读 1001-1500
RFC1050_RPC远程步骤呼叫协议说明书
RFC1055_在串行线路上传输IP数据报的非标准协议
RFC1134_+PPP协议：关于在点到点链路上进行多协议包传送的建议
RFC1142 OSI IS-IS 域内路由协议
RFC1144_低速串行链路上的TCPIP头部压缩
RFC1145 SNMPv2的管理模型
RFC1155_基于TCPIP网络的管理结构和标记
RFC1166_Internet数字
RFC1288_Finger用户信息协议
RFC1298_基于IPX协议的SNMP
RFC1321_MD5 信息-摘要算
RFC1332_PPP Internet 协议控制协议 (IPCP)
RFC1333_PPP 链接质量监控
RFC1355_网络中心数据库的保密和准确性问题
RFC1365 一种IP地址扩展提议
RFC1690 Internet工程与计划组（IEPG）介绍
RFC1691 康奈尔大学数字图书馆文档体系结构
RFC1696 用SMIv2定义的调制解调器MIB
RFC1713_DNS调试工具
RFC1715_地址分配效率比率H
RFC1723_路由信息协议（版本2）
RFC1724_RIP 版本 2 管理系统库(MIB) 扩展
RFC1370_OSPF适用范围声明
RFC1387_RIP（版本2）协议分析

Extreme Networks SLX 9640高性能固定路由器商品介绍说明书

ExtremeRouting? SLX 9640
Built to Suit Your Business Needs Ext rem e Elem ent s are t he b uild ing b locks t hat allow you t o t ailor your net w ork t o your sp ecific b usiness environm ent , g oals, and ob ject ives. They enab le t he creat ion of an A ut onom ous Net w ork t hat d elivers t he p osit ive exp eriences and b usiness out com es m ost im p ort ant t o your org anizat ion.
W W W.EXTREMENETW
1
Flexib le Bo rd er Ro ut ing w it h Int ernet Scale, Ult ra-Deep Buffers,
MPLS and EVPN
The SLX 964 0 is a very p ow erful com p act d eep b uffer Int ernet b ord er rout er, p rovid ing a cost -efficient solut ion t hat is p urp ose-b uilt for t he m ost d em and ing service p rovid er and ent erp rise d at a cent ers and MA N/ WA N ap p licat ions. The rob ust syst em archit ect ure sup p ort ed by SLX-OS and a versat ile feat ure set includ ing IPv4 , IPv6, and MPLS/ VPLS w it h Carrier Et hernet 2.0 and OA M cap ab ilit ies t o p rovid e d ep loym ent flexib ilit y.

SMTP协议RFC文档中文版

RFC821 简单邮件传输协议（SMTP）(RFC821 SIMPLE MAIL TRANSFER PROTOCOL)目录1. 介绍 22. SMTP模型 33. SMTP过程 43.1. MAIL 43.2. 转发 53.3. 确认和扩展 63.4. 发送信件(mailing)和获得信件(sending) 7 3.5. 打开和关闭73.6. 转发 83.7. 域93.8. 改变角色94. SMTP说明94.1. SMTP命令94.1.1. 命令语法94.1.2. COMMAND语法格式134.2. SMTP响应154.3. 命令和应答序列164.4. 状态图174.5. 详细内容184.5.1. 最小实现184.5.2. 透明性194.5.3. 大小19附录 A TCP传输服务19附录 B NCP传输服务20附录 C NITS 20附录 D X.25传输服务 20附录 E 应答码构成方法20附录 F 一些例子22参考资料361. 介绍简单邮件传输协议（SMTP）的目标是可靠高效地传送邮件，它独立于传送子系统而且仅要求一条可以保证传送数据单元顺序的通道。

附录A，B，C和D描述了不同传送服务下SMTP的使用。

在名词表中还定义了本文档中使用的术语。

SMTP的一个重要特点是它能够在传送中接力传送邮件，传送服务提供了进程间通信环境（IPCE），此环境可以包括一个网络，几个网络或一个网络的子网。

理解到传送系统（或IPCE）不是一对一的是很重要的。

进程可能直接和其它进程通过已知的IPCE通信。

邮件是一个应用程序或进程间通信。

邮件可以通过连接在不同IPCE上的进程跨网络进行邮件传送。

更特别的是，邮件可以通过不同网络上的主机接力式传送。

2. SMTP模型SMTP设计基于以下通信模型：针对用户的邮件请求，发送SMTP建立与接收SMTP之间建立一个双向传送通道。

接收SMTP可以是最终接收者也可以是中间传送者。

SMTP命令由发送SMTP发出，由接收SMTP接收，而应答则反方面传送。

RFC1035(中文)域名-实现及标准

注意，尽管在域名中大小写字母是允许的，但是对大小写不做区别。即，两个名称有相同的拼写，但有不同的大小写，被看作是相同的。
标签必须遵守 ARPANET 主机名称规则。它们必须以字母开始，以字母或数字结束，内部字符仅可以是字母、数字和连字符号。对长度也有某些限制。标签必须是 63 个字符或更少。
P. Mockapetris ISI
November 1987
3-4-1 A RDATA格式 3-4-2 WKS RDATA格式 3-5 IN-ADDR.ARPA域 3-6 定义新的类型、类和专用名称空间第4章消息 4-1 格式 4-1-1 首部部分格式 4-1-2 问题部分格式 4-1-3 资源记录格式 4-1-4 消息压缩 4-2 传送 4-2-1 UDP应用 4-2-2 TCP应用第5章主文件 5-1 格式 5-2 定义区域的主文件的应用 5-3 主文件举例第6章名称服务器实现 6-1 架构 6-1-1 控制 6-1-2 数据库 6-1-3 时间 6-2 标准查询处理 6-3 区域更新和重新加载处理 6-4 反向查询(可选) 6-4-1 反向查询和响应的内容 6-4-2 反向查询和响应举例 6-4-3 反向查询处理 6-5 完整查询和响应第7章解析器实现 7-1 将用户请求转换为查询 7-2 发送查询 7-3 处理响应 7-4 使用缓存器第8章邮件支持 8-1 邮件交换绑定 8-2 邮箱绑定(试验) 第9章参考文献和参考书目原文索引
这个功能性结构隔离了用户接口问题、失败恢复问题和在解析器中分发的问题，隔离了名称服务器中数据库更新问题和刷新问题。
2-2 一般配置主机能够以多种方法分享域名服务器，取决于或者主机运行检索来自域系统的信息的程
序、运行检索来自名称服务器(这些服务器回答来自其他主机的查询)信息的程序，或者主机运行两种程序功能的各种组合。最简单和或许也是最典型的配置如图 1 所示。

学习网络常用的RFC文档的名称

学习网络常用的RFC文档的名称双语RFC --RFC中英文对照版rfc1050中文版-远程过程调用协议规范rfc1055中文版-在串行线路上传输IP数据报的非标准协议rfc1057中文版-RFC:远程过程调用协议说明第二版rfc1058中文版-路由信息协议（Routing Information Protocol）rfc1073中文版-RFC1073 Telnet窗口尺寸选项rfc1075中文版-远距离矢量多播选路协议rfc1088中文版-在NetBIOS网络上传输IP数据报的标准rfc1090中文版-SMTP在X.25上rfc1091中文版-TELNET终端类型选项rfc1094中文版-RFC1094 网络文件系统协议rfc1096中文版-Telnet X显示定位选项rfc1097中文版-Telnet潜意识-信息选项rfc1112中文版-主机扩展用于IP多点传送rfc1113中文版-Internet电子邮件保密增强：Part1-消息编码和鉴别过程rfc1132中文版-802．2分组在IPX网络上传输的标准rfc1144中文版-低速串行链路上的TCP/IP头部压缩rfc1155中文版-基于TCP/IP网络的管理结构和标记rfc1191中文版-RFC1191 路径MTU发现rfc1332中文版-RFC1332 端对端协议网间协议控制协议（IPCP）rfc1333中文版-PPP 链路质量监控rfc1334中文版-PPP 身份验证协议rfc1387中文版-RIP（版本2）协议分析rfc1388中文版-RIP协议版本2rfc1433中文版-直接ARPrfc1445中文版-SNMPv2的管理模型rfc1582中文版-扩展RIP以支持按需链路rfc1618中文版-ISDN上的PPP(点对点)协议rfc1661中文版-RFC1661 PPP协议rfc1723中文版-路由信息协议（版本2）rfc1738中文版-统一资源定位器（URL）rfc1769中文版-简单网络时间协议( SNTP)rfc1771中文版-边界网关协议版本4（BGP-4）rfc1827中文版-IP封装安全载荷（ESP）rfc1883中文版-Internet协议，版本6（IPv6）说明书rfc1939中文版-POP3协议rfc1945中文版-超文本传输协议 -- HTTP/1.0rfc1994中文版-PPP挑战握手认证协议(CHAP)rfc1997中文版-RFC1997 BGP团体属性rfc2002中文版-IP移动性支持rfc204中文版-利用报路rfc2105中文版-Cisco 系统的标签交换体系结构纵览rfc2281中文版-Cisco热备份路由协议（）rfc2283中文版-BGP-4的多协议扩展rfc2326中文版-实时流协议(RTSP)rfc2328中文版-OSPF版本2rfc2516中文版-在以太网上传输PPP的方法（PPPoE）rfc2526中文版-IPv6保留的子网任意传送地址rfc2547中文版-BGP/MPLS VPNsrfc2616中文版-超文本传输协议——HTTP/1.1rfc2702中文版-基于MPLS的流量工程要求rfc2706中文版-RFC2706—电子商务域名标准rfc2756中文版-超文本缓存协议(HTCP/0.0)rfc2764中文版-IP VPN的框架体系rfc2773中文版-使用KEA和SKIPJACK加密rfc2774中文版-HTTP扩展框架rfc2781中文版-UTF-16, 一种ISO 10646的编码方式rfc2784中文版-通用路由封装rfc2793中文版-用于文本交谈的RTP负载rfc2796中文版-BGP路由反射rfc2917中文版-核心 MPLSIP VPN 体系结构rfc2918中文版-BGP-4（边界网关协议）的路由刷新功能rfc2923中文版-TCP的路径MTU发现问题rfc3003中文版-Audio/mpeg 媒体类型rfc3005中文版-IETF 讨论列表许可证rfc3007中文版-安全的域名系统动态更新rfc3018中文版-统一内存空间协议规范rfc3022中文版-传统IP网络地址转换（传统NAT）rfc3032中文版-RFC3032 MPLS标记栈编码rfc3033中文版-用于Internet协议的信息域和协议标识符在Q.2941类属标识符和Q.2957 User-to-user信令中的分配rfc3034中文版-标签转换在帧中继网络说明书中的使用rfc3037中文版-RFC3037 标记分配协议的适用范围（RFC3037 LDP Applicability）rfc3058中文版-IDEA加密算法在CMS上的使用rfc3059中文版-服务定位协议的属性列表扩展rfc3061中文版-对象标识符的一种URN姓名空间rfc3062中文版-LDAP口令修改扩展操作rfc3063中文版-MPLS（多协议标签交换）环路预防机制rfc3066中文版-语言鉴定标签rfc3067中文版-事件对象描述和转换格式要求rfc3069中文版-VLAN聚合实现IP地址有效分配rfc3070中文版-基于帧中继的第二层隧道协议rfc3072中文版-结构化数据交换格式rfc3074中文版-DHCP 负载平衡算法rfc3078中文版-RFC3078微软点到点加密(MPPE)协议rfc3081中文版-将区块扩展交换协议（BEEP）核心映射到传输控制协议（TCP）rfc3083中文版-遵循DOCSIS的Cable Modem和CMTS的PBI 的管理信息数据库rfc3085中文版-新闻型标记语言（NewsML）资源的URN名字空间rfc3090中文版-域名系统在区域状况下的安全扩展声明rfc3091中文版-Pi数字生成协议rfc3093中文版-防火墙增强协议rfc3550中文版-RTP：实时应用程序传输协议rfc457中文版-TIPUGrfc697中文版-FTP的CWD命令rfc698中文版-TELNET扩展ASCII选项rfc775中文版-面向目录的 FTP 命令rfc779中文版-TELNET的SEND-LOCATION选项rfc792中文版-RFC792- Internet控制信息协议（ICMP）rfc821中文版-RFC821 简单邮件传输协议（SMTP）rfc826中文版-以太网地址转换协议或转换网络协议地址为48比特以太网地址用于在以太网硬件上传输rfc854中文版-TELNET协议规范rfc855中文版-TELNET选项规范rfc856中文版-RFC856 TELNET二进制传输rfc857中文版-RFC 857 TELNET ECHO选项rfc858中文版-RFC 858 TELNET SUPPRESS GO AHEAD选项rfc859中文版-RFC 859 TELNET的STATUS选项rfc860中文版-RFC 860 TELNET TIMING MARK选项rfc861中文版-RFC 861 TELNET扩展选项-LISTrfc862中文版-RFC 862 Echo 协议rfc868中文版-RFC868 时间协议rfc894中文版-IP 数据包通过以太网网络传输标准rfc903中文版-反向地址转换协议rfc930中文版-Telnet终端类型选项（RFC930——T elnet Terminal Type Option）rfc932中文版-子网地址分配方案rfc937中文版-邮局协议 (版本2)rfc948中文版-IP数据报通过IEEE802.3网络传输的两种方法rfc949中文版-FTP 未公开的独特命令rfc951中文版-引导协议(BOOTP)rfc962中文版-TCP-4 的最初rfc974中文版-邮件路由与域名系统rfc975中文版-自治联邦。

ssh协议是udp还是tcp

编号：_______________本资料为word版本，可以直接编辑和打印，感谢您的下载ssh协议是udp还是tcp甲方：___________________乙方：___________________日期：___________________ssh协议是udp还是tcp篇一：tcp、udp及socket 的关系1.4tcp、udp 及socket 的关系《更安全的linux网络》第1章防火墙的基本概念，在本书的开始将详尽讲解与防火墙相关的tcp/ip技术。

此外，对于防火墙的原理、种类、架构及其优、缺点，在本章中也都有详尽的介绍。

本节为大家介绍tcp、udp及socket的关系。

1.4tcp、udp 及socket 的关系在了解了信息在网络上是如何传递之后，接下来，我们要认识传输层中另一个重要的标记-- port。

port在传输层中是一个很重要的概念，我们之所以能够在一台主机上同时执行多个服务，都得归功于port的概念。

在开始谈port之前，我们先来了解什么是socket osocket是指一个上面有很多“洞”的东西，比如说，计算机主机板上cpu的插座，我们称其为socket478或socket939等，而socket上面这些洞在传输层中则称为port ,在os的网络系统中会有两个socket ,分另U为tcpsocket 及第i页共ii页udpsocket , socket上各有65536个洞，我们把它称为port0、portl、port2port65535。

我们以图1-11为例来说明port的用途，图的左边为client 端、图的右边则为server 端，在server 端主机上，我们假设执行了web、ssh及dns这3项服务，在tcp/ip 的网络规范中，每一个网络应用程序执行时都会占用一个port ,如server 端的webservice 启动时，就会占用在tcpsocket 中的port80，简称为tcpport80，而sshservice 是tcpport22、dnsservice 则为udpport53，因此我们可以说，tcpport80 代表webservice 程序，tcpport22 代表sshservice 程序，而udpport53 即代表dnsservice 程序。

RFC 3550 中文版

RFC 3550 中文文档翻译说明译者注：本文档提供给那些有一定英语基础的读者，所以文中涉及到的专有词汇均以英文原词给出，给读者带来的不便请凉解。

本文档知识产权声明部分仅供参考，如有涉及到与知识产权有关的地方请参看原文或询问相关法律人式。

由于工作量太大，附录部分没有列入译者翻译之列，请谅解。

感谢罗总及工程师gale 给予的支持和帮助。

由于译者水平有限和时间冲忙，文中一定有错译的地方，译者尽量将这种情况降到最小，但不排除译者本身就理解错误的情况，欢迎任何对本书有兴趣的读者提出任何质疑，邮箱：xingkongft@，QQ：601211088。

Network Working Group H。

Schulzrinne Request for Comments：3550 Columbia UniversityObsoletes：1889 S。

Casner Category： Standards Track Packet DesignR。

Frederick Blue Coat Systems Inc 。

V。

JacobsonPacket DesignJuly 2003 RTP ：应用于实时应用的传输协议备忘录的状态：本文档讲述了一种Internet 社区的Internet 标准跟踪协议，它需要进一步进行讨论和建议以得到改进。

请参考最新版的“Internet 正式协议标准”(STD1)来获得本协议的标准化程度和状态。

本备忘录的发布不受任何限制。

所有权利保留。

摘要：本文档阐述了实时传输协议（RTP)，RTP 提供了端到端的网络传输功能，适合于通过多播或单播网络服务的实时数据传输应用，例如：音频，视频等，RTP 不强调资源保留(does not address resource reservation) 而且并不保证实时服务QOS(quality-of-service)，实时控制协议(RTCP)对数据进行监控和提供最小的控制和鉴别功能。

rfc中常用的测试协议

rfc中常用的测试协议引言在计算机网络领域中，为了确保网络协议的正确性和稳定性，测试协议起到了至关重要的作用。

RFC（Request for Comments）是一系列文件，用于描述互联网相关协议、过程和技术。

在RFC中，也包含了一些常用的测试协议，用于验证和评估网络协议的功能和性能。

本文将介绍RFC中常用的测试协议，并深入探讨其原理和应用。

二级标题1：PING协议三级标题1.1：概述PING协议是一种常用的网络测试协议，用于测试主机之间的连通性。

它基于ICMP （Internet Control Message Protocol）协议，通过发送ICMP Echo Request报文并等待目标主机的ICMP Echo Reply报文来判断目标主机是否可达。

三级标题1.2：工作原理PING协议的工作原理如下： 1. 发送方主机生成一个ICMP Echo Request报文，并将目标主机的IP地址作为目的地。

2. 发送方主机将报文发送到网络中。

3.中间路由器收到报文后，将报文转发到下一跳路由器。

4. 目标主机收到ICMP Echo Request报文后，生成一个ICMP Echo Reply报文，并将其发送回发送方主机。

5. 发送方主机收到ICMP Echo Reply报文后，通过比较报文中的标识符和序列号等字段，判断目标主机是否可达。

三级标题1.3：应用场景PING协议在网络中的应用非常广泛，常用于以下场景： - 测试主机之间的连通性，判断网络是否正常工作。

- 测试网络延迟，通过计算ICMP Echo Request报文的往返时间来评估网络质量。

- 排查网络故障，通过检查ICMP Echo Reply报文中的错误码来定位故障原因。

二级标题2：Traceroute协议三级标题2.1：概述Traceroute协议用于跟踪数据包从源主机到目标主机经过的路径。

它通过发送一系列的UDP报文，并在每个报文中设置不同的TTL（Time to Live）值来实现。

RFC3263(sip)中文

Session Initiation Protocol (SIP):SIP服务器定位本文档状态本文档为Internet 团体定义了一个Internet standards track协议。

并且请求对这个文档进行讨论以便改进。

请参阅当前版本的”InternetOfficalProtocol Stands”(STD1)来确认本文档的标准化状态以及本协议的状态。

对本文档的发布是没有限制的。

同样SIP也支持服务端在客户端的主机失效的情况下使用DNS来向备份的客户端发送应答。

本文档描述了这些DNS的详细过程。

1．介绍SIP（RFC3261）是一个客户端/服务端的协议，它用来创建用户之间的通讯会话和管理用户之间的通讯会话的。

SIP 的终端系统叫做UA（用户代理），中间的结点叫做proxy 服务器。

一个典型的SIP配置，叫做一个SIP”梯形”,就像在图1中表示的一样。

在这个图中，呼叫方在domain A(UA1),希望呼叫在domain B的用户Joe(Joe@b)。

为了完成这个呼叫，他首先和在自己域内部的proxy1（domain A中的proxy 1）。

Proxy1向被叫方域的proxy 服务器（proxy2）转发这个请求。

Proxy2转发这个请求到被叫方，UA2。

作为呼叫流的一部分，proxy1需要确定domain B的SIP服务器。

为了能够确定这个，proxy1 使用DNS的步骤，使用SRV[2]和NAPTR[3]记录来确定这个地址。

本文档描述了SIP使用DNS的相关问题，并且提供了解决方法。

2．DNS需要解决的相关问题为了能够解决上边介绍的一般呼叫流所需要确定的呼叫双方两方面的问题，我们需要使用DNS。

TCPIP-Traffic_control

IP flow
Edge router
流量规范流量规范
DS classifier Multi-byte classifier Policy Maker Queue scheduler
2002-11-21 4
Queue scheduler
交换技术与通信网国家重点实验室宽带网研究中心
高速路由器
输入单元输入输入单元输入分类/策略计量/标记高速传输交换机构输出单元输出单元队列管理 1 2 N 输出
比特向量
将多维搜索转化为一维搜索定义比特向量首先在各个分量上查找
得到对应的比特向量然后将个比特向量 "与" 找到对应的规则 BV = rst 100 110 010
r s
t
12
特点:
速度快不适于大规则集 001
100 111 101 001 2002-11-21 交换技术与通信网国家重点实验室宽带网研究中心
规则冲突(conflict)
显然,p 可能匹配 R 中的多条规则流分类实际上是在 R 中搜索与 p 的最佳匹配规则 r
交换技术与通信网国家重点实验室宽带网研究中心
2002-11-21 10
快速流分类算法的设计
线性查找
线性搜索规则集 R 空间,找到最佳匹配的规则时间复杂度高 O(N),速度慢,不易扩展
否则认为不符合tspec不符合tspec分组可进行标记丢弃等允许的最大突发度容量令牌补充速率令牌桶令牌使用20021121交换技术与通信网国家重点实验室宽带网研究中心24基于令牌桶的标记器公平标记器fminout三色标记器tcm单速率三色标记器srtcmrfc2697双速率三色标记器trtcmrfc2698多媒体彩色标记器mmcm三色直接丢弃20021121交换技术与通信网国家重点实验室宽带网研究中心25公平标记器fminout双色标记工作过程分组到达时令牌桶中有足够令牌则将分组标记成in否则将分组标记成out网络将对标记成的分组采用不同的处理方法将分组划分成了不同的等级突发度令牌桶输入分组ipipip输出分组out20021121交换技术与通信网国家重点实验室宽带网研究中心26三色标记器tcm单速率三色标记srtcm将业务流ip分组分别标记为红黄绿三色对应不同的等级大小分别为cbs和ebs共享cirnewtokensoverflowtokens20021121交换技术与通信网国家重点实验室宽带网研究中心27三色标记器tcm双速率三色标记srtcm将业务流ip分组分别标记为红黄绿三色用两个令牌桶

常见网络端口对照表(Excel)

端口协议描述状态0TCP,UDP保留端口；不使用（若发送过程不准备接受回复消息，则可以作为源端口）官方1TCP,UDP TCPMUX（传输控制协议端口服务多路开关选择器）官方5TCP,UDP RJE（远程作业登录）官方7TCP,UDP ECHO（回显）协议官方9TCP,UDP DISCARD（丢弃）协议官方11TCP,UDP SYSTAT协议官方13TCP,UDP DAYTIME协议官方15TCP,UDP NETSTAT协议官方17TCP,UDP QOTD（Quote of the Day，每日引用）协议官方18TCP,UDP消息发送协议官方19TCP,UDP CHARGEN（字符发生器）协议官方20TCP,UDP文件传输协议（FTP） - 默认数据端口官方21TCP,UDP文件传输协议（FTP） - 控制端口官方22TCP,UDP SSH (Secure Shell) - 远程登录协议，用于安全登录文件传输（SCP，SFTP）及端口重官方23TCP,UDP Telnet 终端仿真协议 - 未加密文本通信官方25TCP,UDP SMTP（简单邮件传输协议） - 用于邮件服务器间的电子邮件传递官方26TCP,UDP RSFTP - 一个简单的类似FTP的协议非官方35TCP,UDP QMS Magicolor 2 printer非官方37TCP,UDP TIME时间协议官方39TCP,UDP Resource Location Protocol（资源定位协议）官方41TCP,UDP图形官方42TCP,UDP Host Name Server（主机名服务）官方42TCP,UDP WINS（WINS主机名服务）非官方43TCP WHOIS 协议官方49TCP,UDP TACACS 登录主机协议官方53TCP,UDP DNS（域名服务系统）官方56TCP,UDP远程访问协议官方57TCP MTP，邮件传输协议67UDP BOOTP（BootStrap协议）服务；同时用于DHCP（动态主机设定协议）官方68UDP BOOTP 客户端；同时用于DHCP（动态主机设定协议）官方69UDP TFTP（小型文件传输协议）官方70TCP Gopher信息检索协议官方79TCP Finger协议官方80TCP HTTP（超文本传输协议）- 用于传输网页官方81TCP HTTP预备（超文本传输协议）官方81TCP Torpark - Onion routing ORport非官方82UDP Torpark - 控制端口非官方88TCP Kerberos - 认证代理官方101TCP主机名102TCP ISO-TSAP 协议107TCP远程Telnet协议109TCP POP（Post Office Protocol），“邮局协议”，第2版110TCP POP3（“邮局协议”，第3版）- 用于接收电子邮件官方111TCP,UDP Sun协议官方113TCP ident - old server identification system, 仍然被IRC 服务器用来认证它的用户官方115TCP SFTP, 简单文件传输协议117TCP UUCP-PATH118TCP,UDP SQL 服务官方119TCP NNTP (Network News Transfer Protocol) - 用来收取新闻组的消息官方123UDP NTP (Network Time Protocol) - used for time synchronization官方135TCP,UDP EPMAP (End Point Mapper) / Microsoft RPC Locator Service官方137TCP,UDP NetBIOS NetBIOS Name Service官方138TCP,UDP NetBIOS NetBIOS Datagram Service官方139TCP,UDP NetBIOS NetBIOS Session Service官方143TCP,UDP IMAP4 (Internet Message Access Protocol 4) - used for retrieving E-mails官方152TCP,UDP BFTP, Background File Transfer Program153TCP,UDP SGMP, Simple Gateway Monitoring Protocol156TCP,UDP SQL Service官方158TCP,UDP DMSP, Distributed Mail Service Protocol161TCP,UDP SNMP (Simple Network Management Protocol)官方162TCP,UDP SNMPTRAP官方170TCP Print-srv179TCP BGP (Border Gateway Protocol)官方194TCP IRC (Internet Relay Chat)官方201TCP,UDP AppleTalk Routing Maintenance209TCP,UDP The Quick Mail Transfer Protocol213TCP,UDP IPX官方218TCP,UDP MPP, Message Posting Protocol220TCP,UDP IMAP, Interactive Mail Access Protocol, version 3259TCP,UDP ESRO, Efficient Short Remote Operations264TCP,UDP BGMP，Border Gateway Multicast Protocol308TCP Novastor Online Backup官方311TCP Apple Server-Admin-Tool, Workgroup-Manager-Tool318TCP,UDP TSP, Time Stamp Protocol323TCP,UDP IMMP, Internet Message Mapping Protocol383TCP,UDP HP OpenView HTTPs Operations Agent366TCP,UDP SMTP, Simple Mail Transfer Protocol. ODMR, On-Demand Mail Relay369TCP,UDP Rpc2portmap官方371TCP,UDP ClearCase albd官方384TCP,UDP A Remote Network Server System387TCP,UDP AURP, AppleTalk Update-based Routing Protocol389TCP,UDP LDAP (Lightweight Directory Access Protocol)官方401TCP,UDP UPS Uninterruptible Power Supply官方411TCP Direct Connect Hub port非官方412TCP Direct Connect Client-To-Client port非官方427TCP,UDP SLP (Service Location Protocol)官方443TCP HTTPS - HTTP Protocol over TLS/SSL (encrypted transmission)官方444TCP,UDP SNPP，Simple Network Paging Protocol445TCP Microsoft-DS (Active Directory，Windows shares, Sasser worm，Agobot, Zobotwor官方445UDP Microsoft-DS SMB file sharing官方464TCP,UDP Kerberos Change/Set password官方465TCP Cisco protocol官方465TCP SMTP over SSL非官方475TCP tcpnethaspsrv (Hasp services, TCP/IP version)官方497TCP dantz backup service官方500TCP,UDP ISAKMP，IKE-Internet Key Exchange官方502TCP,UDP Modbus，Protocol512TCP exec, Remote Process Execution512UDP comsat, together with biff：notifies users of new c.q. yet unread e-mail513TCP Login513UDP Who514TCP rsh514UDP syslog protocol - used for system logging官方515TCP Line Printer Daemon protocol - used in LPD printer servers517UDP Talk518UDP NTalk520TCP efs520UDP Routing - RIP官方513UDP Router524TCP,UDP NCP (NetWare Core Protocol) is used for a variety things such as access to pr官方525UDP Timed, Timeserver530TCP,UDP RPC官方531TCP,UDP AOL Instant Messenger, IRC非官方532TCP netnews533UDP netwall, For Emergency Broadcasts540TCP UUCP (Unix-to-Unix Copy Protocol)官方542TCP,UDP commerce (Commerce Applications)官方543TCP klogin, Kerberos login544TCP kshell, Kerberos Remote shell546TCP,UDP DHCPv6 client547TCP,UDP DHCPv6 server548TCP AFP（Apple Filing Protocol）550UDP new-rwho, new-who554TCP,UDP RTSP (Real Time Streaming Protocol)官方556TCP Remotefs, rfs, rfs_server560UDP rmonitor, Remote Monitor561UDP monitor563TCP,UDP NNTP protocol over TLS/SSL (NNTPS)官方587TCP email message submission（SMTP） (RFC 2476)官方591TCP FileMaker 6.0 (and later) Web Sharing (HTTP Alternate, see port 80)官方593TCP,UDP HTTP RPC Ep Map（RPC over HTTP, often used by DCOM services and Microsoft Exc官方604TCP TUNNEL631TCP,UDP IPP，Internet Printing Protocol636TCP,UDP LDAP over SSL (encrypted transmission, also known as LDAPS)官方639TCP,UDP MSDP, Multicast Source Discovery Protocol646TCP LDP, Label Distribution Protocol647TCP DHCP Failover Protocol648TCP RRP, Registry Registrar Protocol652TCP DTCP, Dynamic Tunnel Configuration Protocol654UDP AODV, Ad hoc On-Demand Distance Vector665TCP sun-dr, Remote Dynamic Reconfiguration非官方666UDP毁灭战士，电脑平台上的一系列第一人称射击游戏。

常见的网络服务端口

常见的⽹络服务端⼝常见的⽹络服务端⼝⼴泛公认的端⼝列表1. ⼴泛公认的端⼝，是⼤部分⼴泛使⽤的程序或协议的默认端⼝，但实际使⽤时，由于安全等原因，系统管理员可以⾃⾏指定端⼝号。

2. 这⾥的端⼝号通常指的是服务器端的端⼝号。

⽐如⽹页浏览器会在本机的36406端⼝和远端的80端⼝间建⽴连接。

服务端的80端⼝就是默认的⼴泛公认的端⼝。

⽽本机的36406则只是临时端⼝。

端⼝0-1023是公认端⼝号，即已经公认定义或为将要公认定义的软件保留的，⽽1024-65535是并没有公共定义的端⼝号，⽤户可以⾃⼰定义这些端⼝的作⽤。

那么端⼝号到底有什么作⽤呢？当⼀台电脑启动了⼀个可以让远程其他电脑访问的程序，那么它就要开启⾄少⼀个端⼝号来让外界访问。

我们可以把没有开启端⼝号的电脑看作是⼀个密封的房间，密封的房间当然不可能接受外界的访问，所以当系统开启了⼀个可以让外界访问的程序后它⾃然需要在房间上开⼀个窗⼝来接受来⾃外界的访问，这个窗⼝就是端⼝。

那么为什么要给端⼝编号来区分它们呢，既然⼀个程序开了⼀个端⼝，那么不是外部信息都可以通过这个开启的端⼝来访问了吗？答案是不可以。

为什么呢？因为数据是⽤端⼝号来通知传输层协议送给哪个软件来处理的，数据是没有智慧的，如果很多的程序共⽤⼀个端⼝来接受数据的话，那么当外界的⼀个数据包送来后传输层就不知道该送给哪⼀个软件来处理，这样势必将导致混乱。

源端⼝号⼀般是由系统⾃⼰动态⽣成的⼀个从1024-65535的号码，当⼀台计算机A通过⽹络访问计算机B时，如果它需要对⽅返回数据的话，它也会随机创建⼀个⼤于1023的端⼝，告诉B返回数据时把数据送到⾃⼰的哪个端⼝，然后软件开始侦听这个端⼝，等待数据返回。

⽽B收到数据后会读取数据包的源端⼝号和⽬的端⼝号，然后记录下来，当软件创建了要返回的数据后就把原来数据包中的原端⼝号作为⽬的端⼝号，⽽把⾃⼰的端⼝号作为原端⼝号，也就是说把收到的数据包中的原和⽬的反过来，然后再送回A，A再重复这个过程如此反复直到数据传输完成。

RFC协议标准

标准参考文档链路层协议PPP(Point-to-Point Protocol)：RFC 1332： The PPP Internet Protocol Control Protocol (IPCP)RFC 1334： PPP Authentication ProtocolsRFC 1552： The PPP Internetworking Packet Exchange Control Protocol (IPXCP) RFC 1570： PPP LCP Extensions(实现了其中的callback选项)RFC 1661： The Point-to-Point Protocol (PPP)RFC 1877： PPP Internet Protocol Control Protocol Extensions for Name Server AddressesRFC 1990： The PPP Multilink Protocol (MP)RFC 1994： PPP Challenge Handshake Authentication Protocol (CHAP)RFC 2509： IP Header Compression over PPPRFC 1962： The PPP Compression Control Protocol (CCP)RFC 1974： PPP Stac LZS Compression ProtocoldX25、LAPB(Link Access Protocol Balanced)：RFC1613：Cisco Systems X.25 over TCP(XOT)RFC1598：PPP in X.25RFC1461：SNMP MIB extension for MultiProtocol Interconnect over X.25RFC1382： SNMP MIB Extension for the X.25 Packet LayerRFC1381： SNMP MIB Extension for X.25 LAPBRFC1356： Multiprotocol Interconnect on X.25 and ISDN in the Packet ModeRFC1236： IP to X.121 Address Mapping for DDNRFC1226： Internet Protocol Encapsulation of AX.25 FramesRFC1090： SMTP on X.25RFC1086： ISO-TP0 bridge between TCP and X.25RFC874： Critique of X.25RFC1236： IP to X.121 Address Mapping for DDNRFC1133： Routing between the NSFNET and the DDNCisco-HDLC：Cisco-HDLC是CISCO自己设计的一个协议,没有可参考的标准Frame Relay：RFC1294/1490： Multiprotocol Interconnect over Frame RelayRFC1293： Inverse Address Resolution Protocol(INARP)RFC1315： Management Information Base for Frame Relay DTEsITU-T Q933附录A：帧中继本地管理接口（LMI）协议ANSI T1.617附录D：帧中继本地管理接口（LMI）协议ISDN(Integrated Services Digital Network)：ITU-T Q.931建议(网络层)ITU-T Q.921建议(链路层)IP层协议RFC791： Internet Protocol. (IP)RFC792： Internet Control Message Protocol (ICMP)RFC793： TRANSMISSION CONTROL PROTOCOL (TCP)RFC896： Congestion Control in IP/TCP InternetworksRFC768： User Datagram Protocol (UDP)RFC 826： An Ethernet Address Resolution Protocol (ARP)Socket： Unix标准路由协议RIP(Routing Information Protocol)：RFC1058： Routing Information ProtocolRFC1723： RIP Version 2RFC2082： RIP-2 MD5 AuthenticationOSPF(Open Shortest Path First)：RFC2328： OSPF Version 2RFC1793： Extending OSPF to Support Demand CircuitsIGRP(Interior Gateway Routing Protocol)：IGRP协议无标准RFC，与CISCO保持兼容BGP(Border Gateway Protocol)：RFC1771： A Border Gateway Protocol 4(BGP-4)RFC1772： Application of the Border Gateway Protocol in the Internet (BGP-4) RFC1965： Autonomous System Confederations for BGPRFC1966： BGP Route Reflection -- An alternative to full mesh IBGPRFC1997： BGP Community AttributeRFC2439： BGP Route Flap Damping网络安全RADIUS(Remote Authentication Dial In User Service)：RFC2138： Remote Authentication Dial In User Service (RADIUS)RFC2139： RADIUS AccountingGRE(Generic Routing Encapsulation)：RFC1701： Generic Roouting Encapsulation (老版本)RFC1702： Generic Routing Encapsulation over IPv4 networksRFC2784： Generic Roouting Encapsulation (新版本)RFC2667： IP Tunnel MIBIPSEC(IP Security)：RFC1825： Security Architechure for the Internet Protocol (老版本)RFC2401： Security Architechure for the Internet Protocol (新版本)AH(Authentication Header)协议：RFC2402： IP Authentication HeaderRFC1321： The MD5 Message-Digest AlgorithmRFC2104： HMAC: Keyed-Hashing for Message AuthenticationRFC2085： IP Authentication with Replay PreventionRFC2403： The Use of HMAC-MD5-96 within ESP and AHRFC2404： The Use of HMAC-SHA-1-96 within ESP and AHESP(Encapsulating Security Payload)：RFC2406： IP Encapsulating Security Payload (ESP)RFC2405： The ESP DES-CBC Cipher Algorithm With Explicit IVIKE(Internet Key Exchange)：RFC2408：Internet Security Association and Key Management Protocol (ISAKMP) RFC2409：The Internet Key Exchange (IKE)RFC2407：The Internet IP Security Domain of Interpretation for ISAKMP (IPSEC DOI)L2TP(Layer 2 Tunnel Protocol)：RFC2661：Layer 2 Tunnel ProtocolNAT(Network Address Translator)：RFC1631：The IP Network Address Translator (NAT)RFC2663：IP Network Address Translator (NAT) Terminology and Considerations 网络管理SNMP(Simple Network Management Protocol)：RFC 1157： Simple Network Management Protocol (SNMP)。

CiTRANS R8000-10产品描述-烽火

CiTRANS R8000-10核心路由器设备产品描述烽火通信科技股份有限公司2014年11月目录1CITRANS R8000-10概述 (3)2设计依据与执行标准 (3)3设备体系结构及产品功能特性 (9)3.1系统架构 (9)3.2功能特性 (9)3.3组网互通能力 (11)3.4IP特性 (11)3.5路由功能 (11)3.6MPLS特性 (12)3.7VPN特性 (12)3.8组播功能 (12)3.9Q O S特性 (13)3.10OAM特性 (13)3.11时钟特性 (14)3.11.1物理层时钟同步 (14)3.11.2IEEE 1588V2时钟同步 (14)3.12可靠性 (16)3.12.1访问控制列表ACL (16)3.12.2流量监管 (16)3.12.3抗攻击能力 (17)4系统硬件、软件结构 (18)4.1系统硬件 (18)4.1.1设备外形与尺寸机柜 (18)4.1.2以太网业务卡 (18)4.1.3TDM业务卡 (19)4.1.4主控交换板 (19)4.2软件结构 (19)5CITRANS R8000-10设备保护能力介绍 (20)5.1设备级保护 (20)5.2网络级保护 (21)5.3协议级的可靠性 (21)6管理控制功能和安全机制介绍 (21)6.1管理控制功能 (21)6.2网络安全 (21)7系统参数介绍 (22)7.110GE光接口性能 (22)7.2GE光接口指标 (22)7.3电气性能 (22)7.4功耗及熔丝标准 (23)7.5尺寸及承重 (23)7.6工作环境 (23)1 CiTRANS R8000-10概述CiTRANS R8000是电信级高端路由器产品。

聚焦移动回传网络演进和发展需求，烽火基于分布式硬件处理平台和IP/MPLS软件架构，推出的下一代路由产品，具有超大容量、高处理性能、高可靠性、高扩展性等特点，与CiTRANS R800系列IP RAN等产品配合组网，形成结构完整、层次清晰的IP网络解决方案，可以在IP/MPLS网络上提供强大的IP 路由和多业务支持功能，在各种大型IP网络的核心及汇聚节点，为运营商提供3G/4G移动业务承载、大客户VPN、宽带接入、IPTV统一业务承载。

rfc5085(PW VCCV)

Network Working Group T. Nadeau, Ed. Request for Comments: 5085 C. Pignataro, Ed. Category: Standards Track Cisco Systems, Inc. December 2007 Pseudowire Virtual Circuit Connectivity Verification (VCCV):A Control Channel for PseudowiresStatus 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 document describes Virtual Circuit Connectivity Verification(VCCV), which provides a control channel that is associated with apseudowire (PW), as well as the corresponding operations andmanagement functions (such as connectivity verification) to be usedover that control channel. VCCV applies to all supported accesscircuit and transport types currently defined for PWs.RFC 5085 PW VCCV December 2007 Table of Contents1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 31.1. Specification of Requirements . . . . . . . . . . . . . . 52. Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . 53. Overview of VCCV . . . . . . . . . . . . . . . . . . . . . . . 64. CC Types and CV Types . . . . . . . . . . . . . . . . . . . . 85. VCCV Control Channel for MPLS PWs . . . . . . . . . . . . . . 10 5.1. VCCV Control Channel Types for MPLS . . . . . . . . . . . 10 5.1.1. In-Band VCCV (Type 1) . . . . . . . . . . . . . . . . 11 5.1.2. Out-of-Band VCCV (Type 2) . . . . . . . . . . . . . . 12 5.1.3. TTL Expiry VCCV (Type 3) . . . . . . . . . . . . . . . 12 5.2. VCCV Connectivity Verification Types for MPLS . . . . . . 13 5.2.1. ICMP Ping . . . . . . . . . . . . . . . . . . . . . . 13 5.2.2. MPLS LSP Ping . . . . . . . . . . . . . . . . . . . . 13 5.3. VCCV Capability Advertisement for MPLS PWs . . . . . . . . 135.3.1. VCCV Capability Advertisement LDP Sub-TLV . . . . . . 146. VCCV Control Channel for L2TPv3/IP PWs . . . . . . . . . . . . 15 6.1. VCCV Control Channel Type for L2TPv3 . . . . . . . . . . . 16 6.2. VCCV Connectivity Verification Type for L2TPv3 . . . . . . 17 6.2.1. L2TPv3 VCCV using ICMP Ping . . . . . . . . . . . . . 17 6.3. L2TPv3 VCCV Capability Advertisement for L2TPv3 . . . . . 176.3.1. L2TPv3 VCCV Capability AVP . . . . . . . . . . . . . . 177. Capability Advertisement Selection . . . . . . . . . . . . . . 198. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 8.1. VCCV Interface Parameters Sub-TLV . . . . . . . . . . . . 19 8.1.1. MPLS VCCV Control Channel (CC) Types . . . . . . . . . 19 8.1.2. MPLS VCCV Connectivity Verification (CV) Types . . . . 20 8.2. PW Associated Channel Type . . . . . . . . . . . . . . . . 21 8.3. L2TPv3 Assignments . . . . . . . . . . . . . . . . . . . . 21 8.3.1. Control Message Attribute Value Pairs (AVPs) . . . . . 21 8.3.2. Default L2-Specific Sublayer Bits . . . . . . . . . . 21 8.3.3. ATM-Specific Sublayer Bits . . . . . . . . . . . . . . 218.3.4. VCCV Capability AVP Values . . . . . . . . . . . . . . 229. Congestion Considerations . . . . . . . . . . . . . . . . . . 2310. Security Considerations . . . . . . . . . . . . . . . . . . . 2411. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 2512. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 12.1. Normative References . . . . . . . . . . . . . . . . . . . 26 12.2. Informative References . . . . . . . . . . . . . . . . . . 26RFC 5085 PW VCCV December 2007 1. IntroductionThere is a need for fault detection and diagnostic mechanisms thatcan be used for end-to-end fault detection and diagnostics for aPseudowire, as a means of determining the PW's true operationalstate. Operators have indicated in [RFC4377] and [RFC3916] that such a tool is required for PW operation and maintenance. This documentdefines a protocol called Virtual Circuit Connectivity Verification(VCCV) that satisfies these requirements. VCCV is, in its simplestdescription, a control channel between a pseudowire's ingress andegress points over which connectivity verification messages can besent.The Pseudowire Edge-to-Edge Emulation (PWE3) Working Group defines a mechanism that emulates the essential attributes of atelecommunications service (such as a T1 leased line or Frame Relay) over a variety of Packet Switched Network (PSN) types [RFC3985].PWE3 is intended to provide only the minimum necessary functionality to emulate the service with the required degree of faithfulness forthe given service definition. The required functions of PWs include encapsulating service-specific bit streams, cells, or PDUs arrivingat an ingress port and carrying them across an IP path or MPLStunnel. In some cases, it is necessary to perform other operations, such as managing their timing and order, to emulate the behavior and characteristics of the service to the required degree offaithfulness.From the perspective of Customer Edge (CE) devices, the PW ischaracterized as an unshared link or circuit of the chosen service.In some cases, there may be deficiencies in the PW emulation thatimpact the traffic carried over a PW and therefore limit theapplicability of this technology. These limitations must be fullydescribed in the appropriate service-specific documentation.For each service type, there will be one default mode of operationthat all PEs offering that service type must support. However,optional modes have been defined to improve the faithfulness of theemulated service, as well as to offer a means by which olderimplementations may support these services.Figure 1 depicts the architecture of a pseudowire as defined in[RFC3985]. It further depicts where the VCCV control channel resides within this architecture, which will be discussed in detail shortly.RFC 5085 PW VCCV December 2007 |<-------------- Emulated Service ---------------->|| |<---------- VCCV ---------->| || |<------- Pseudowire ------->| || | | || | |<-- PSN Tunnel -->| | || V V V V |V AC +----+ +----+ AC V+-----+ | | PE1|==================| PE2| | +-----+| |----------|............PW1.............|----------| || CE1 | | | | | | | | CE2 || |----------|............PW2.............|----------| |+-----+ ^ | | |==================| | | ^ +-----+^ | +----+ +----+ | | ^| | Provider Edge 1 Provider Edge 2 | || | | |Customer | | CustomerEdge 1 | | Edge 2| || |Native service Native serviceFigure 1: PWE3 VCCV Operation Reference ModelFrom Figure 1, Customer Edge (CE) routers CE1 and CE2 are attached to the emulated service via Attachment Circuits (ACs), and to each ofthe Provider Edge (PE) routers (PE1 and PE2, respectively). An ACcan be a Frame Relay Data Link Connection Identifier (DLCI), an ATMVirtual Path Identifier / Virtual Channel Identifier (VPI/VCI), anEthernet port, etc. The PE devices provide pseudowire emulation,enabling the CEs to communicate over the PSN. A pseudowire existsbetween these PEs traversing the provider network. VCCV providesseveral means of creating a control channel over the PW, between the PE routers that attach the PW.Figure 2 depicts how the VCCV control channel is associated with the pseudowire protocol stack.RFC 5085 PW VCCV December 2007 +-------------+ +-------------+| Layer2 | | Layer2 || Emulated | < Emulated Service > | Emulated || Services | | Services |+-------------+ +-------------+| | VCCV/PW | ||Demultiplexer| < Control Channel > |Demultiplexer|+-------------+ +-------------+| PSN | < PSN Tunnel > | PSN |+-------------+ +-------------+| Physical | | Physical |+-----+-------+ +-----+-------+| || ____ ___ ____ || _/ \___/ \ _/ \__ || / \__/ \_ || / \ |+--------| MPLS or IP Network |---+\ /\ ___ ___ __ _/\_/ \____/ \___/ \____/Figure 2: PWE3 Protocol Stack Reference Model including the VCCVControl ChannelVCCV messages are encapsulated using the PWE3 encapsulation asdescribed in Sections 5 and 6, so that they are handled and processed in the same manner (or in some cases, a similar manner) as the PWPDUs for which they provide a control channel. These VCCV messagesare exchanged only after the capability (expressed as two VCCV typespaces, namely the VCCV Control Channel and Connectivity Verification Types) and desire to exchange such traffic has been advertisedbetween the PEs (see Sections 5.3 and 6.3), and VCCV types chosen.1.1. Specification of RequirementsThe 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].2. AbbreviationsAC Attachment Circuit [RFC3985].AVP Attribute Value Pair [RFC3931].CC Control Channel (used as CC Type).RFC 5085 PW VCCV December 2007 CE Customer Edge.CV Connectivity Verification (used as CV Type).CW Control Word [RFC3985].L2SS L2-Specific Sublayer [RFC3931].LCCE L2TP Control Connection Endpoint [RFC3931].OAM Operation and Maintenance.PE Provider Edge.PSN Packet Switched Network [RFC3985].PW Pseudowire [RFC3985].PW-ACH PW Associated Channel Header [RFC4385].VCCV Virtual Circuit Connectivity Verification.3. Overview of VCCVThe goal of VCCV is to verify and further diagnose the pseudowireforwarding path. To this end, VCCV is comprised of differentcomponents:o a means of signaling VCCV capabilities to a peer PE,o an encapsulation for the VCCV control channel messages that allows the receiving PE to intercept, interpret, and process them locally as OAM messages, ando specifications for the operation of the various VCCV operationalmodes transmitted within the VCCV messages.When a pseudowire is first signaled using the Label DistributionProtocol (LDP) [RFC4447] or the Layer Two Tunneling Protocol version 3 (L2TPv3) [RFC3931], a message is sent from the initiating PE to the receiving PE requesting that a pseudowire be set up. This messagehas been extended to include VCCV capability information (seeSection 4). The VCCV capability information indicates to thereceiving PE which combinations of Control Channel (CC) andConnectivity Verification (CV) Types it is capable of receiving. If the receiving PE agrees to establish the PW, it will return itscapabilities in the subsequent signaling message to indicate which CCRFC 5085 PW VCCV December 2007 and CV Types it is capable of processing. Precedence rules for which CC and CV Type to choose in cases where more than one is specified in this message are defined in Section 7 of this document.Once the PW is signaled, data for the PW will flow between the PEsterminating the PW. At this time, the PEs can begin transmittingshould be noted that because of the number of combinations ofoptional and mandatory data-plane encapsulations for PW data traffic, VCCV defines a number of Control Channel (CC) and ConnectivityVerification (CV) types in order to support as many of these aspossible. While designed to support most of the existingcombinations (both mandatory and optional), VCCV does define adefault CC and CV Type combination for each PW Demultiplexer type, as will be described in detail later in this document.VCCV can be used both as a fault detection and/or a diagnostic toolfor pseudowires. For example, an operator can periodically invokeVCCV on a timed, on-going basis for proactive connectivityverification on an active pseudowire, or on an ad hoc or as-neededbasis as a means of manual connectivity verification. When invoking VCCV, the operator triggers a combination of one of its various CCTypes and one of its various CV Types. The CV Types include LSP Ping [RFC4379] for MPLS PWs, and ICMP Ping [RFC0792] [RFC4443] for bothMPLS and L2TPv3 PWs. We define a matrix of acceptable CC and CV Type combinations further in this specification.The control channel maintained by VCCV can additionally carry faultdetection status between the endpoints of the pseudowire.Furthermore, this information can then be translated into the native OAM status codes used by the native access technologies, such as ATM, Frame-Relay or Ethernet. The specific details of such statusinterworking is out of the scope of this document, and is only noted here to illustrate the utility of VCCV for such purposes. Completedetails can be found in [MSG-MAP] and [RFC4447].RFC 5085 PW VCCV December 2007 4. CC Types and CV TypesThe VCCV Control Channel (CC) Type defines several possible types of control channel that VCCV can support. These control channels can in turn carry several types of protocols defined by the ConnectivityVerification (CV) Type. VCCV potentially supports multiple CV Types concurrently, but it only supports the use of a single CC Type. The specific type or types of VCCV packets that can be accepted and sent by a router are indicated during capability advertisement asdescribed in Sections 5.3 and 6.3. The various VCCV CV Typessupported are used only when they apply to the context of the PWdemultiplexer in use. For example, the LSP Ping CV Type should only be used when MPLS Labels are utilized as PW Demultiplexer.Once a set of VCCV capabilities is received and advertised, a CC Type and CV Type(s) that match both the received and transmittedcapabilities can be selected. That is, a PE router needs to onlyallow Types that are both received and advertised to be selected,performing a logical AND between the received and transmitted bitflag fields. The specific CC Type and CV Type(s) are then chosen withinthe constraints and rules specified in Section 7. Once a specific CC Type has been chosen (i.e., it matches both the transmitted andreceived VCCV CC capability), transmitted and replied to, this CCType MUST be the only one used until such time as the pseudowire isre-signaled. In addition, based on these rules and the proceduresdefined in Section 5.2 of [RFC4447], the pseudowire MUST be re-signaled if a different set of capabilities types is desired. Therelevant portion of Section 5.2 of [RFC4447] is:Interface Parameter Sub-TLVNote that as the "interface parameter sub-TLV" is part of theFEC, the rules of LDP make it impossible to change theinterface parameters once the pseudowire has been set up.The CC and CV Type indicator fields are defined as 8-bit bitmasksused to indicate the specific CC or CV Type or Types (i.e., none,one, or more) of control channel packets that may be sent on the VCCV control channel. These values represent the numerical valuecorresponding to the actual bit being set in the bitfield. Thedefinition of each CC and CV Type is dependent on the PW typecontext, either MPLS or L2TPv3, within which it is defined.RFC 5085 PW VCCV December 2007 Control Channel (CC) Types:The defined values for CC Types for MPLS PWs are:MPLS Control Channel (CC) Types:Bit (Value) Description============ ==========================================Bit 0 (0x01) - Type 1: PWE3 Control Word with 0001b asfirst nibble (PW-ACH, see [RFC4385])Bit 1 (0x02) - Type 2: MPLS Router Alert LabelBit 2 (0x04) - Type 3: MPLS PW Label with TTL == 1Bit 3 (0x08) - ReservedBit 4 (0x10) - ReservedBit 5 (0x20) - ReservedBit 6 (0x40) - ReservedBit 7 (0x80) - ReservedThe defined values for CC Types for L2TPv3 PWs are:L2TPv3 Control Channel (CC) Types:Bit (Value) Description============ ==========================================Bit 0 (0x01) - L2-Specific Sublayer with V-bit setBit 1 (0x02) - ReservedBit 2 (0x04) - ReservedBit 3 (0x08) - ReservedBit 4 (0x10) - ReservedBit 5 (0x20) - ReservedBit 6 (0x40) - ReservedBit 7 (0x80) - ReservedConnectivity Verification (CV) Types:The defined values for CV Types for MPLS PWs are:MPLS Connectivity Verification (CV) Types:Bit (Value) Description============ ==========================================Bit 0 (0x01) - ICMP PingBit 1 (0x02) - LSP PingBit 2 (0x04) - ReservedBit 3 (0x08) - ReservedBit 4 (0x10) - ReservedBit 5 (0x20) - ReservedRFC 5085 PW VCCV December 2007 Bit 6 (0x40) - ReservedBit 7 (0x80) - ReservedThe defined values for CV Types for L2TPv3 PWs are:L2TPv3 Connectivity Verification (CV) Types:Bit (Value) Description============ ==========================================Bit 0 (0x01) - ICMP PingBit 1 (0x02) - ReservedBit 2 (0x04) - ReservedBit 3 (0x08) - ReservedBit 4 (0x10) - ReservedBit 5 (0x20) - ReservedBit 6 (0x40) - ReservedBit 7 (0x80) - ReservedIf none of the types above are supported, the entire CC and CV TypeIndicator fields SHOULD be transmitted as 0x00 (i.e., all bits in the bitfield set to 0) to indicate this to the peer.If no capability is signaled, then the peer MUST assume that the peer has no VCCV capability and follow the procedures specified in thisdocument for this case.5. VCCV Control Channel for MPLS PWsWhen MPLS is used to transport PW packets, VCCV packets are carriedover the MPLS LSP as defined in this section. In order to apply IPmonitoring tools to a PW, an operator may configure VCCV as a control channel for the PW between the PE's endpoints [RFC3985]. Packetssent across this channel from the source PE towards the destinationPE either as in-band traffic with the PW's data, or out-of-band. In all cases, the control channel traffic is not forwarded past the PEendpoints towards the Customer Edge (CE) devices; instead, VCCVmessages are intercepted at the PE endpoints for exceptionprocessing.5.1. VCCV Control Channel Types for MPLSAs already described in Section 4, the capability of which controlchannel types (CC Type) are supported is advertised by a PE. Oncethe receiving PE has chosen a CC Type mode to use, it MUST continueusing this mode until such time as the PW is re-signaled. Thus, if a new CC Type is desired, the PW must be torn-down and re-established.RFC 5085 PW VCCV December 2007 Ideally, such a control channel would be completely in-band (i.e.,following the same data-plane faith as PW data). When a control word is present on the PW, it is possible to indicate the control channel by setting a bit in the control word header (see Section 5.1.1).Section 5.1.1 through Section 5.1.3 describe each of the currentlydefined VCCV Control Channel Types (CC Types).5.1.1. In-Band VCCV (Type 1)CC Type 1 is also referred to as "PWE3 Control Word with 0001b asfirst nibble". It uses the PW Associated Channel Header (PW-ACH);see Section 5 of [RFC4385].The PW set-up protocol [RFC4447] determines whether a PW uses acontrol word. When a control word is used, and that CW uses the"Generic PW MPLS Control Word" format (see Section 3 of [RFC4385]), a Control Channel for use of VCCV messages can be created by using the PW Associated Channel CW format (see Section 5 of [RFC4385]).The PW Associated Channel for VCCV control channel traffic is defined in [RFC4385] as shown in Figure 3: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+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|0 0 0 1|Version| Reserved | Channel Type |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 3: PW Associated Channel HeaderThe first nibble is set to 0001b to indicate a channel associatedwith a pseudowire (see Section 5 of [RFC4385] and Section 3.6 of[RFC4446]). The Version and the Reserved fields are set to 0, andthe Channel Type is set to 0x0021 for IPv4 and 0x0057 for IPv6payloads.For example, Figure 4 shows how the Ethernet [RFC4448] PW-ACH wouldbe received containing an LSP Ping payload corresponding to a choice of CC Type of 0x01 and a CV Type of 0x02: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+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|0 0 0 1|0 0 0 0|0 0 0 0 0 0 0 0| 0x21 (IPv4) or 0x57 (IPv6) |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 4: PW Associated Channel Header for VCCVRFC 5085 PW VCCV December 2007 It should be noted that although some PW types are not required tocarry the control word, this type of VCCV can only be used for those PW types that do employ the control word when it is in use. Further, this CC Type can only be used if the PW CW follows the "Generic PWMPLS Control Word" format. This mode of VCCV operation MUST besupported when the control word is present.5.1.2. Out-of-Band VCCV (Type 2)CC Type 2 is also referred to as "MPLS Router Alert Label".A VCCV control channel can alternatively be created by using the MPLS router alert label [RFC3032] immediately above the PW label. Itshould be noted that this approach could result in a different Equal Cost Multi-Path (ECMP) hashing behavior than pseudowire PDUs, andthus result in the VCCV control channel traffic taking a path whichdiffers from that of the actual data traffic under test. Please see Section 2 of [RFC4928].CC Type 2 can be used whether the PW is set-up with a Control Wordpresent or not.This is the preferred mode of VCCV operation when the Control Word is not present.If the Control Word is in use on this PW, it MUST also be includedbefore the VCCV message. This is done to avoid the different ECMPhashing behavior. In this case, the CW uses the PW-ACH formatdescribed in Section 5.1.1 (see Figures 3 and 4). If the ControlWord is not in use on this PW, the VCCV message follows the PW Label directly.5.1.3. TTL Expiry VCCV (Type 3)CC Type 3 is also referred to as "MPLS PW Label with TTL == 1".The TTL of the PW label can be set to 1 to force the packet to beprocessed within the destination router's control plane. Thisapproach could also result in a different ECMP hashing behavior andVCCV messages taking a different path than the PW data traffic.CC Type 3 can be used whether the PW is set-up with a Control Wordpresent or not.If the Control Word is in use on this PW, it MUST also be includedbefore the VCCV message. This is done to avoid the different ECMPhashing behavior. In this case, the CW uses the PW-ACH formatRFC 5085 PW VCCV December 2007 described in Section 5.1.1 (see Figures 3 and 4). If the ControlWord is not in use on this PW, the VCCV message follows the PW Label directly.5.2. VCCV Connectivity Verification Types for MPLS5.2.1. ICMP PingWhen this optional connectivity verification mode is used, an ICMPEcho packet using the encoding specified in [RFC0792] (ICMPv4) or[RFC4443] (ICMPv6) achieves connectivity verification.Implementations MUST use ICMPv4 [RFC0792] if the signaling for VCCVused IPv4 addresses, or ICMPv6 [RFC4443] if IPv6 addresses were used. If the pseudowire is set up statically, then the encoding MUST usethat which was used for the pseudowire in the configuration.5.2.2. MPLS LSP PingThe LSP Ping header MUST be used in accordance with [RFC4379] andMUST also contain the target FEC Stack containing the sub-TLV of sub- Type 8 for the "L2 VPN endpoint", 9 for "FEC 128 Pseudowire(deprecated)", 10 for "FEC 128 Pseudowire", or 11 for the "FEC 129Pseudowire". The sub-TLV value indicates the PW to be verified.5.3. VCCV Capability Advertisement for MPLS PWsTo permit the indication of the type or types of PW controlchannel(s) and connectivity verification mode or modes over aparticular PW, a VCCV parameter is defined in Section 5.3.1 that isused as part of the PW establishment signaling. When a PE signals a PW and desires PW OAM for that PW, it MUST indicate this during PWestablishment using the messages defined in Section 5.3.1.Specifically, the PE MUST include the VCCV interface parameter sub-TLV (0x0C) assigned in [RFC4446] in the PW set-up message [RFC4447]. The decision of the type of VCCV control channel is left completelyto the receiving control entity, although the set of choices is given by the sender in that it indicates the control channels andconnectivity verification type or types that it can understand. The receiver SHOULD choose a single Control Channel Type from the matchbetween the choices sent and received, based on the capabilityadvertisement selection specified in Section 7, and it MUST continue to use this type for the duration of the life of the control channel. Changing Control Channel Types after one has been established to bein use could potentially cause problems at the receiving end andcould also lead to interoperability issues; thus, it is NOTRECOMMENDED.RFC 5085 PW VCCV December 2007 When a PE sends a label mapping message for a PW, it uses the VCCVparameter to indicate the type of OAM control channels andconnectivity verification type or types it is willing to receive and can send on that PW. A remote PE MUST NOT send VCCV messages before the capability of supporting the control channel(s) (and connectivity verification type(s) to be used over them) is signaled. Then, it can do so only on a control channel and using the connectivityverification type(s) from the ones indicated.If a PE receives VCCV messages prior to advertising capability forthis message, it MUST discard these messages and not reply to them.In this case, the PE SHOULD increment an error counter and optionally issue a system and/or SNMP notification to indicate to the systemadministrator that this condition exists.When LDP is used as the PW signaling protocol, the requesting PEindicates its configured VCCV capability or capabilities to theremote PE by including the VCCV parameter with appropriate options in the VCCV interface parameter sub-TLV field of the PW ID FEC TLV (FEC 128) or in the interface parameter sub-TLV of the Generalized PW IDFEC TLV (FEC 129). These options indicate which control channel and connectivity verification types it supports. The requesting PE MAYindicate that it supports multiple control channel options, and indoing so, it agrees to support any and all indicated types iftransmitted to it. However, it MUST do so in accordance with therules stipulated in Section 5.3.1 (VCCV Capability Advertisement Sub- TLV.)Local policy may direct the PE to support certain OAM capability and to indicate it. The absence of the VCCV parameter indicates that no OAM functions are supported by the requesting PE, and thus thereceiving PE MUST NOT send any VCCV control channel traffic to it.The reception of a VCCV parameter with no options set MUST be ignored as if one is not transmitted at all.The receiving PE similarly indicates its supported control channeltypes in the label mapping message. These may or may not be the same as the ones that were sent to it. The sender should examine the set that is returned to understand which control channels it mayestablish with the remote peer, as specified in Sections 4 and 7.Similarly, it MUST NOT send control channel traffic to the remote PE for which the remote PE has not indicated it supports.5.3.1. VCCV Capability Advertisement LDP Sub-TLV[RFC4447] defines an Interface Parameter Sub-TLV field in the LDP PW ID FEC (FEC 128) and an Interface Parameters TLV in the LDPGeneralized PW ID FEC (FEC 129) to signal different capabilities for。

RFC2373

组织：中国互动出版网（/）RFC文档中文翻译计划(/compters/emook/aboutemook.htm)E-mail：ouyang@译者：党红梅（snowlily danghongmei@）译文发布时间：2001－4－27版权：本中文翻译文档版权归中国互动出版网所有。

可以用于非商业用途自由转载，但必须保留本文档的翻译及版权信息。

Network Working Group R. Hinden Request for Comments: 2373 Nokia Obsoletes: 1884 S. Deering Category: Standards Track Cisco Systems July 1998IPv6寻址体系结构（RFC2373: IP Version 6 Addressing Architecture）本备忘录的状态本文档讲述了一种Internet社区的Internet标准跟踪协议，它需要进一步进行讨论和建议以得到改进。

请参考最新版的“Internet正式协议标准”(STD1)来获得本协议的标准化程度和状态。

本备忘录的发布不受任何限制。

本文件包括I P v 6 寻址模型、I P v 6 地址的文字表示、I P v 6 单播地址、任意点播地址和组播地址的定义以及I P v 6 节点需要的地址。

目录摘要 11．简介 22. IPv6 寻址 22.1 寻址模型 32.2 地址的文本表示 32.3 地址前缀的文本表示 42.4 地址类型表示 52.5 单播地址 52.5.1 接口标识符 62.5.2 未指定地址72.5.3 回返地址72.5.4 嵌有IPv4 地址的IPv6 地址72.5.5 NSAP 地址72.5.6 IPX 地址82.5.7 可集聚全球单播地址82.5.8 本地用IPv6 单播地址82.6 任意点播地址92．6．1要求的任意点播地址92.7 组播地址102.7.1 预定义的组播地址112.7.2 新IPv6 组播地址的分配122.8 节点要求的地址123. 安全性考虑13附录A 创建EUI-64 接口标识符13A.1 具有EUI-64 标识符的链路或节点13A.2 具有IEEE 802 48 位MAC 地址的链路或节点13A.3 具有非全球标识符的链路14A.4 无标识符的链路14附录B 文本表示的ABNF 描述 15附录C 对RFC 1884 的修改15参考资料16作者联系方法17版权说明171．简介本技术规范定义了I P v 6 的寻址体系结构。