rfc3056.Connection of IPv6 Domains via IPv4 Clouds
IPv6 演进技术要求 基于 IPv6 段路由(SRv6)的 IP 承载网络-最新国标
IPv6演进技术要求第2部分：基于IPv6段路由(SRv6)的IP承载网络1 范围本文件规定了基于SRv6的IP承载网络总体架构、基于SRv6的设备层技术要求及基于SRv6的管控层技术要求。
本文件适用于支持SRv6的IP承载网络。
2 规范性引用文件下列文件中的内容通过文中的规范性引用而构成本文件必不可少的条款。
其中，注日期的引用文件，仅该日期对应的版本适用于本文件；不注日期的引用文件，其最新版本（包括所有的修改单）适用于本文件。
IETF RFC2493 IPv6规范中的通用报文隧道（Generic Packet Tunneling in IPv6 Specification）IETF RFC4659 IPv6 VPN场景中的BGP-MPLS IP虚拟私有网络扩展（BGP-MPLS IP Virtual Private Network (VPN) Extension for IPv6 VPN）IETF RFC5549 通告带有IPv6下一跳地址的IPv4网络层可达性信息（Advertising IPv4 Network Layer Reachability Information with an IPv6 Next Hop）IETF RFC6437 IPv6流标签规范（IPv6 Flow Label Specification）IETF RFC6514 MPLS/BGP IP VPN中提供组播服务的BGP编码与处理（BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs）IETF RFC7432 基于BGP MPLS的EVPN（BGP MPLS-Based Ethernet VPN）IETF RFC7606 改进的BGP更新消息的错误处理（Revised Error Handling for BGP UPDATE Messages）IETF RFC8200 互联网协议第六版规范（Internet Protocol, Version 6 (IPv6) Specification）IETF RFC8402 分段路由架构（Segment Routing Architecure）IETF RFC8754 IPv6段路由报头(IPv6 Segment Routing Header)IETF RFC8986 SRv6网络编程（Segment Routing over IPv6 (SRv6) Network Programming）IETF RFC9252 基于SRv6的BGP overlay业务(BGP Overlay Services Based on Segment Routing over IPv6 (SRv6))IETF RFC9352 支持SRv6的ISIS扩展(IS-IS Extensions to Support Segment Routing over the IPv6 Data Plane）GB/T XXXXX IPv6演进技术要求第4部分：基于IPv6段路由(SRv6)的网络编程GB/T XXXXX IPv6演进技术要求第7部分：基于IPv6段路由(SRv6)的业务链GB/T XXXXX IPv6演进技术要求第8部分：基于IPv6段路由(SRv6)的报文头压缩GB/T XXXXX IPv6演进技术要求第9部分：基于IPv6段路由(SRv6)的网络故障保护3 术语、定义和缩略语3.1 术语和定义下列术语和定义适用于本文件。
rfc4191.Default Router Preferences and More-Specific Routes
Network Working Group R. Draves Request for Comments: 4191 D. Thaler Category: Standards Track Microsoft November 2005 Default Router Preferences and More-Specific RoutesStatus 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. Copyright NoticeCopyright (C) The Internet Society (2005).AbstractThis document describes an optional extension to Router Advertisement messages for communicating default router preferences and more-specific routes from routers to hosts. This improves the ability of hosts to pick an appropriate router, especially when the host ismulti-homed and the routers are on different links. The preferencevalues and specific routes advertised to hosts require administrative configuration; they are not automatically derived from routingtables.1. IntroductionNeighbor Discovery [RFC2461] specifies a conceptual model for hoststhat includes a Default Router List and a Prefix List. Hosts sendRouter Solicitation messages and receive Router Advertisementmessages from routers. Hosts populate their Default Router List and Prefix List based on information in the Router Advertisementmessages. A conceptual sending algorithm uses the Prefix List todetermine if a destination address is on-link and uses the DefaultRouter List to select a router for off-link destinations.In some network topologies where the host has multiple routers on its Default Router List, the choice of router for an off-link destination is important. In some situations, one router may provide much better performance than another for a destination. In other situations,choosing the wrong router may result in a failure to communicate.(Section 5 gives specific examples of these scenarios.)Draves & Thaler Standards Track [Page 1]This document describes an optional extension to Neighbor DiscoveryRouter Advertisement messages for communicating default routerpreferences and more-specific routes from routers to hosts. Thisimproves the ability of hosts to pick an appropriate router for anoff-link destination.Note that since these procedures are applicable to hosts only, theforwarding algorithm used by the routers (including hosts withenabled IP forwarding) is not affected.Neighbor Discovery provides a Redirect message that routers can useto correct a host’s choice of router. A router can send a Redirectmessage to a host, telling it to use a different router for aspecific destination. However, the Redirect functionality is limited to a single link. A router on one link cannot redirect a host to arouter on another link. Hence, Redirect messages do not help multi- homed (through multiple interfaces) hosts select an appropriaterouter.Multi-homed hosts are an increasingly important scenario, especially with IPv6. In addition to a wired network connection, like Ethernet, hosts may have one or more wireless connections, like 802.11 orBluetooth. In addition to physical network connections, hosts mayhave virtual or tunnel network connections. For example, in addition to a direct connection to the public Internet, a host may have atunnel into a private corporate network. Some IPv6 transitionscenarios can add additional tunnels. For example, hosts may have6to4 [RFC3056] or configured tunnel [RFC2893] network connections.This document requires that the preference values and specific routes advertised to hosts require explicit administrative configuration.They are not automatically derived from routing tables. Inparticular, the preference values are not routing metrics and it isnot recommended that routers "dump out" their entire routing tablesto hosts.We use Router Advertisement messages, instead of some other protocol like RIP [RFC2080], because Router Advertisements are an existingstandard, stable protocol for router-to-host communication.Piggybacking this information on existing message traffic fromrouters to hosts reduces network overhead. Neighbor Discovery shares with Multicast Listener Discovery the property that they both define host-to-router interactions, while shielding the host from having to participate in more general router-to-router interactions. Inaddition, RIP is unsuitable because it does not carry route lifetimes so it requires frequent message traffic with greater processingoverheads.Draves & Thaler Standards Track [Page 2]The mechanisms specified here are backwards-compatible, so that hosts that do not implement them continue to function as well as they didpreviously.1.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].2. Message Formats2.1. Preference ValuesDefault router preferences and preferences for more-specific routesare encoded the same way.Preference values are encoded as a two-bit signed integer, asfollows:01 High00 Medium (default)11 Low10 Reserved - MUST NOT be sentNote that implementations can treat the value as a two-bit signedinteger.Having just three values reinforces that they are not metrics andmore values do not appear to be necessary for reasonable scenarios. Draves & Thaler Standards Track [Page 3]2.2. Changes to Router Advertisement Message FormatThe changes from Neighbor Discovery [RFC2461] Section 4.2 and[RFC3775] Section 7.1 are as follows: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+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cur Hop Limit |M|O|H|Prf|Resvd| Router Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reachable Time | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Retrans Timer | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options ...+-+-+-+-+-+-+-+-+-+-+-+-Fields:Prf (Default Router Preference)2-bit signed integer. Indicates whether to prefer thisrouter over other default routers. If the Router Lifetimeis zero, the preference value MUST be set to (00) by thesender and MUST be ignored by the receiver. If the Reserved (10) value is received, the receiver MUST treat the value as if it were (00).Resvd (Reserved)A 3-bit unused field. It MUST be initialized to zero by the sender and MUST be ignored by the receiver.Possible Options:Route InformationThese options specify prefixes that are reachable via therouter.Discussion:Note that in addition to the preference value in the message header, a Router Advertisement can also contain a Route Information Optionfor ::/0, with a preference value and lifetime. Encoding apreference value in the Router Advertisement header has someadvantages:Draves & Thaler Standards Track [Page 4]1. It allows for a distinction between the "best router for thedefault route" and the "router least likely to redirect commontraffic", as described below in Section 5.1.2. When the best router for the default route is also the routerleast likely to redirect common traffic (which will be a commoncase), encoding the preference value in the message header is more efficient than sending a separate option.2.3. Route Information Option0 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+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Prefix Length |Resvd|Prf|Resvd| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Route Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix (Variable Length) | . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Fields:Type 24Length 8-bit unsigned integer. The length of the option(including the Type and Length fields) in units of 8octets. The Length field is 1, 2, or 3 depending on the Prefix Length. If Prefix Length is greater than 64, then Length must be 3. If Prefix Length is greater than 0,then Length must be 2 or 3. If Prefix Length is zero,then Length must be 1, 2, or 3.Prefix Length8-bit unsigned integer. The number of leading bits inthe Prefix that are valid. The value ranges from 0 to128. The Prefix field is 0, 8, or 16 octets depending on Length.Prf (Route Preference)2-bit signed integer. The Route Preference indicateswhether to prefer the router associated with this prefix over others, when multiple identical prefixes (fordifferent routers) have been received. If the Reserved(10) value is received, the Route Information Option MUST be ignored.Draves & Thaler Standards Track [Page 5]Resvd (Reserved)Two 3-bit unused fields. They MUST be initialized tozero by the sender and MUST be ignored by the receiver.Route Lifetime32-bit unsigned integer. The length of time in seconds(relative to the time the packet is sent) that the prefix is valid for route determination. A value of all onebits (0xffffffff) represents infinity.Prefix Variable-length field containing an IP address or aprefix of an IP address. The Prefix Length fieldcontains the number of valid leading bits in the prefix. The bits in the prefix after the prefix length (if any)are reserved and MUST be initialized to zero by thesender and ignored by the receiver.Routers MUST NOT include two Route Information Options with the same Prefix and Prefix Length in the same Router Advertisement.Discussion:There are several reasons for using a new Route Information Optioninstead of using flag bits to overload the existing PrefixInformation Option:1. Prefixes will typically only show up in one option, not both, so a new option does not introduce duplication.2. The Route Information Option is typically 16 octets while thePrefix Information Option is 32 octets.3. Using a new option may improve backwards-compatibility with somehost implementations.3. Conceptual Model of a HostThere are three possible conceptual models for a host implementation of default router preferences and more-specific routes, corresponding to different levels of support. We refer to these as type A, type B, and type C.3.1. Conceptual Data Structures for HostsType A hosts ignore default router preferences and more-specificroutes. They use the conceptual data structures described inNeighbor Discovery [RFC2461].Draves & Thaler Standards Track [Page 6]Type B hosts use a Default Router List augmented with preferencevalues, but ignore all Route Information Options. They use theDefault Router Preference value in the Router Advertisement header.They ignore Route Information Options.Type C hosts use a Routing Table instead of a Default Router List.(The Routing Table may also subsume the Prefix List, but that isbeyond the scope of this document.) Entries in the Routing Tablehave a prefix, prefix length, preference value, lifetime, and next-hop router. Type C hosts use both the Default Router Preferencevalue in the Router Advertisement header and Route InformationOptions.When a type C host receives a Router Advertisement, it modifies itsRouting Table as follows. When processing a Router Advertisement, a type C host first updates a ::/0 route based on the Router Lifetimeand Default Router Preference in the Router Advertisement messageheader. Then as the host processes Route Information Options in the Router Advertisement message body, it updates its routing table foreach such option. The Router Preference and Lifetime values in a::/0 Route Information Option override the preference and lifetimevalues in the Router Advertisement header. Updating each route isdone as follows. A route is located in the Routing Table based onthe prefix, prefix length, and next-hop router. If the receivedroute’s lifetime is zero, the route is removed from the Routing Table if present. If a route’s lifetime is non-zero, the route is added to the Routing Table if not present and the route’s lifetime andpreference is updated if the route is already present.For example, suppose hosts receive a Router Advertisement from router X with a Router Lifetime of 100 seconds and a Default RouterPreference of Medium. The body of the Router Advertisement contains a Route Information Option for ::/0 with a Route Lifetime of 200seconds and a Route Preference of Low. After processing the RouterAdvertisement, a type A host will have an entry for router X in itsDefault Router List with a lifetime of 100 seconds. If a type B host receives the same Router Advertisement, it will have an entry forrouter X in its Default Router List with a Medium preference and alifetime of 100 seconds. A type C host will have an entry in itsRouting Table for ::/0 -> router X, with a Low preference and alifetime of 200 seconds. During processing of the RouterAdvertisement, a type C host MAY have a transient state, in which it has an entry in its Routing Table for ::/0 -> router X with a Medium preference and a lifetime of 100 seconds.Draves & Thaler Standards Track [Page 7]3.2. Conceptual Sending Algorithm for HostsType A hosts use the conceptual sending algorithm described inNeighbor Discovery [RFC2461].When a type B host does next-hop determination and consults itsDefault Router List, it primarily prefers reachable routers overnon-reachable routers and secondarily uses the router preferencevalues. If the host has no information about the router’sreachability, then the host assumes the router is reachable.When a type C host does next-hop determination and consults itsRouting Table for an off-link destination, it searches its routingtable to find the route with the longest prefix that matches thedestination, using route preference values as a tie-breaker ifmultiple matching routes have the same prefix length. If the bestroute points to a non-reachable router, this router is remembered for the algorithm described in Section 3.5 below, and the next best route is consulted. This check is repeated until a matching route is found that points to a reachable router, or no matching routes remain.Again, if the host has no information about the router’sreachability, then the host assumes the router is reachable.If there are no routes matching the destination (i.e., no defaultroutes and no more-specific routes), then a type C host SHOULDdiscard the packet and report a Destination Unreachable/No Route ToDestination error to the upper layer.3.3. Destination Cache ManagementWhen a type C host processes a Router Advertisement and updates itsconceptual Routing Table, it MUST invalidate or remove DestinationCache Entries and redo next-hop determination for destinationsaffected by the Routing Table changes.3.4. Client ConfigurabilityType B and C hosts MAY be configurable with preference values thatoverride the values in Router Advertisements received. This isespecially useful for dealing with routers that may not supportpreferences.3.5. Router Reachability ProbingWhen a host avoids using any non-reachable router X and instead sends a data packet to another router Y, and the host would have usedrouter X if router X were reachable, then the host SHOULD probe each such router X’s reachability by sending a single NeighborDraves & Thaler Standards Track [Page 8]Solicitation to that router’s address. A host MUST NOT probe arouter’s reachability in the absence of useful traffic that the host would have sent to the router if it were reachable. In any case,these probes MUST be rate-limited to no more than one per minute per router.This requirement allows the host to discover when router X becomesreachable and to start using router X at that time. Otherwise, thehost might not notice router X’s reachability and continue to use the less-desirable router Y until the next Router Advertisement is sentby X. Note that the router may have been unreachable for reasonsother than being down (e.g., a switch in the middle being down), soit may be up to 30 minutes (the maximum advertisement period) before the next Router Advertisement would be sent.For a type A host (following the algorithm in [RFC2461]), no probing is needed since all routers are equally preferable. A type B or Chost, on the other hand, explicitly probes unreachable, preferablerouters to notice when they become reachable again.3.6. ExampleSuppose a type C host has four entries in its Routing Table:::/0 -> router W with a Medium preference2002::/16 -> router X with a Medium preference2001:db8::/32-> router Y with a High preference2001:db8::/32-> router Z with a Low preferenceand the host is sending to 2001:db8::1, an off-link destination. If all routers are reachable, then the host will choose router Y. Ifrouter Y is not reachable, then router Z will be chosen and thereachability of router Y will be probed. If routers Y and Z are not reachable, then router W will be chosen and the reachability ofrouters Y and Z will be probed. If routers W, Y, and Z are all notreachable, then the host should use Y while probing the reachability of W and Z. Router X will never be chosen because its prefix doesnot match the destination.4. Router ConfigurationRouters SHOULD NOT advertise preferences or routes by default. Inparticular, they SHOULD NOT "dump out" their entire routing table to hosts.Routers MAY have a configuration mode in which an announcement of aspecific prefix is dependent on a specific condition, such asoperational status of a link or presence of the same or another Draves & Thaler Standards Track [Page 9]prefix in the routing table installed by another source, such as adynamic routing protocol. If done, router implementations SHOULDmake sure that announcement of prefixes to hosts is decoupled fromthe routing table dynamics to prevent an excessive load on hostsduring periods of routing instability. In particular, unstableroutes SHOULD NOT be announced to hosts until their stability hasimproved.Routers SHOULD NOT send more than 17 Route Information Options inRouter Advertisements per link. This arbitrary bound is meant toreinforce that relatively few and carefully selected routes should be advertised to hosts.The preference values (both Default Router Preferences and RoutePreferences) SHOULD NOT be routing metrics or automatically derivedfrom metrics: the preference values SHOULD be configured.The information contained in Router Advertisements may change through the actions of system management. For instance, the lifetime orpreference of advertised routes may change, or new routes could beadded. In such cases, the router MAY transmit up toMAX_INITIAL_RTR_ADVERTISEMENTS unsolicited advertisements, using the same rules as in [RFC2461]. When ceasing to be an advertisinginterface and sending Router Advertisements with a Router Lifetime of zero, the Router Advertisement SHOULD also set the Route Lifetime to zero in all Route Information Options.4.1. Guidance to AdministratorsThe High and Low (non-default) preference values should only be used when someone with knowledge of both routers and the network topology configures them explicitly. For example, it could be a commonnetwork administrator, or it could be a customer request to different administrators managing the routers.As one exception to this general rule, the administrator of a router that does not have a connection to the Internet, or is connectedthrough a firewall that blocks general traffic, should configure the router to advertise a Low Default Router Preference.In addition, the administrator of a router should configure therouter to advertise a specific route for the site prefix of thenetwork(s) to which the router belongs. The administrator may alsoconfigure the router to advertise specific routes for directlyconnected subnets and any shorter prefixes for networks to which the router belongs.Draves & Thaler Standards Track [Page 10]For example, if a home user sets up a tunnel into a firewalledcorporate network, the access router on the corporate network end of the tunnel should advertise itself as a default router, but with aLow preference. Furthermore, the corporate router should advertise a specific route for the corporate site prefix. The net result is that destinations in the corporate network will be reached via the tunnel, and general Internet destinations will be reached via the home ISP.Without these mechanisms, the home machine might choose to sendInternet traffic into the corporate network or corporate traffic into the Internet, leading to communication failure because of thefirewall.It is worth noting that the network administrator setting uppreferences and/or more specific routes in Routing Advertisementstypically does not know which kind of nodes (Type A, B, and/or C)will be connected to its links. This requires that the administrator configure the settings that will work in an optimal fashionregardless of which kinds of nodes will be attached. Two examples of how to do so follow.5. Examples5.1. Best Router for ::/0 vs Router Least Likely to RedirectThe best router for the default route is the router with the bestroute toward the wider Internet. The router least likely to redirect traffic depends on the actual traffic usage. The two concepts can be different when the majority of communication actually needs to gothrough some other router.For example, consider a situation in which you have a link with tworouters, X and Y. Router X is the best for 2002::/16. (It’s your6to4 site gateway.) Router Y is the best for ::/0. (It connects to the native IPv6 Internet.) Router X forwards native IPv6 traffic to router Y; router Y forwards 6to4 traffic to router X. If mosttraffic from this site is sent to 2002:/16 destinations, then router X is the one least likely to redirect.To make type A hosts work well, both routers should advertisethemselves as default routers. In particular, if router Y goes down, type A hosts should send traffic to router X to maintain 6to4connectivity, so router X and router Y need to be default routers.To make type B hosts work well, router X should advertise itself with a High default router preference. This will cause type B hosts toprefer router X, minimizing the number of redirects.Draves & Thaler Standards Track [Page 11]To make type C hosts work well, router X should in addition advertise the ::/0 route with a Low preference and the 2002::/16 route with aMedium preference. A type C host will end up with three routes inits routing table: ::/0 -> router X (Low), ::/0 -> router Y (Medium), 2002::/16 -> router X (Medium). It will send 6to4 traffic to router X and other traffic to router Y. Type C hosts will not cause anyredirects.Note that when type C hosts process the Router Advertisement fromrouter X, the Low preference for ::/0 overrides the High defaultrouter preference. If the ::/0 specific route were not present, then a type C host would apply the High default router preference to its::/0 route to router X.5.2. Multi-Homed Host and Isolated NetworkIn another scenario, a multi-homed host is connected to the Internet via router X on one link and to an isolated network via router Y onanother link. The multi-homed host might have a tunnel into afirewalled corporate network, or it might be directly connected to an isolated test network.In this situation, a type A multi-homed host (which has no defaultrouter preferences or more-specific routes) will have no way tointelligently choose between routers X and Y on its Default RouterList. Users of the host will see unpredictable connectivityfailures, depending on the destination address and the choice ofrouter.If the routers are configured appropriately, a multi-homed type Bhost in this same situation would have stable Internet connectivity, but would have no connectivity to the isolated test network.If the routers are configured appropriately, a multi-homed type Chost in this same situation can correctly choose between routers Xand Y. For example, router Y on the isolated network shouldadvertise a Route Information Option for the isolated network prefix. It might not advertise itself as a default router at all (zero Router Lifetime), or it might advertise itself as a default router with aLow preference. Router X should advertise itself as a default router with a Medium preference.6. Security ConsiderationsA malicious node could send Router Advertisement messages, specifying a High Default Router Preference or carrying specific routes, withthe effect of pulling traffic away from legitimate routers. However, a malicious node could easily achieve this same effect in other ways. Draves & Thaler Standards Track [Page 12]For example, it could fabricate Router Advertisement messages with a zero Router Lifetime from the other routers, causing hosts to stopusing the other routes. By advertising a specific prefix, thisattack could be carried out in a less noticeable way. However, this attack has no significant incremental impact on Internetinfrastructure security.A malicious node could also include an infinite lifetime in a RouteInformation Option causing the route to linger indefinitely. Asimilar attack already exists with Prefix Information Options in RFC 2461, where a malicious node causes a prefix to appear as on-linkindefinitely, resulting in a lack of connectivity if it is not. Incontrast, an infinite lifetime in a Route Information Option willcause router reachability probing to continue indefinitely, but will not result in a lack of connectivity.Similarly, a malicious node could also try to overload hosts with alarge number of routes in Route Information Options, or with veryfrequent Route Advertisements. Again, this same attack alreadyexists with Prefix Information Options.[RFC3756] provides more details on the trust models, and there iswork in progress in the SEND WG on securing router discovery messages that will address these problems.7. IANA ConsiderationsSection 2.3 defines a new Neighbor Discovery [RFC2461] option, theRoute Information Option, which has been assigned the value 24 within the numbering space for IPv6 Neighbor Discovery Option Formats.8. AcknowledgementsThe authors would like to acknowledge the contributions of BalashAkbari, Steve Deering, Robert Elz, Tony Hain, Bob Hinden, ChristianHuitema, JINMEI Tatuya, Erik Nordmark, Pekka Savola, KresimirSegaric, and Brian Zill. The packet diagrams are derived fromNeighbor Discovery [RFC2461].9. Normative References[RFC2119] Bradner, S., "Key words for use in RFCs to IndicateRequirement Levels", BCP 14, RFC 2119, March 1997.[RFC2461] Narten, T., Nordmark, E., and W. Simpson, "NeighborDiscovery for IP Version 6 (IPv6)", RFC 2461, December1998.Draves & Thaler Standards Track [Page 13]。
srv6相关标准
SRv6（Segment Routing over IPv6）是一种基于IPv6网络的新型路由技术，它通过在IPv6数据包中添加一个24位的标签来标识不同的路径。
这种技术可以提高网络的可扩展性、灵活性和安全性。
以下是一些与SRv6相关的标准：1. RFC 8210：这是SRv6的基本规范，定义了SRv6的基本概念、操作和实现要求。
2. RFC 8365：这个文档描述了如何使用BGP-LS（Border Gateway Protocol - Link State）协议在IPv6网络中传播SRv6路由信息。
3. RFC 8402：这个文档描述了如何使用MP-BGP（Multiprotocol BGP）协议在IPv6网络中传播SRv6路由信息。
4. RFC 8415：这个文档描述了如何使用IS-IS（Intermediate System to Intermediate System）协议在IPv6网络中传播SRv6路由信息。
5. RFC 8475：这个文档描述了如何使用OSPF（Open Shortest Path First）协议在IPv6网络中传播SRv6路由信息。
6. RFC 8597：这个文档描述了如何使用BFD（Bidirectional Forwarding Detection）协议在IPv6网络中检测SRv6路径的状态。
7. RFC 8795：这个文档描述了如何使用LDP（Label Distribution Protocol）协议在IPv6网络中分发SRv6标签。
8. RFC 8879：这个文档描述了如何使用PCE（Path Computation Element）协议在IPv6网络中计算SRv6路径。
9. RFC 8915：这个文档描述了如何使用SDN（Software-Defined Networking）技术来实现SRv6网络。
10. RFC 9119：这个文档描述了如何使用SRv6技术来实现网络切片。
rfc4891.Using IPsec to Secure IPv6-in-IPv4 Tunnels
Network Working Group R. Graveman Request for Comments: 4891 RFG Security, LLC Category: Informational M. Parthasarathy Nokia P. Savola CSC/FUNET H. Tschofenig Nokia Siemens Networks May 2007 Using IPsec to Secure IPv6-in-IPv4 TunnelsStatus 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 IETF Trust (2007).AbstractThis document gives guidance on securing manually configured IPv6-in- IPv4 tunnels using IPsec in transport mode. No additional protocolextensions are described beyond those available with the IPsecframework.Graveman, et al. Informational [Page 1]Table of Contents1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 32. Threats and the Use of IPsec . . . . . . . . . . . . . . . . . 3 2.1. IPsec in Transport Mode . . . . . . . . . . . . . . . . . 42.2. IPsec in Tunnel Mode . . . . . . . . . . . . . . . . . . . 53. Scenarios and Overview . . . . . . . . . . . . . . . . . . . . 5 3.1. Router-to-Router Tunnels . . . . . . . . . . . . . . . . . 6 3.2. Site-to-Router/Router-to-Site Tunnels . . . . . . . . . . 63.3. Host-to-Host Tunnels . . . . . . . . . . . . . . . . . . . 84. IKE and IPsec Versions . . . . . . . . . . . . . . . . . . . . 95. IPsec Configuration Details . . . . . . . . . . . . . . . . . 10 5.1. IPsec Transport Mode . . . . . . . . . . . . . . . . . . . 115.2. Peer Authorization Database and Identities . . . . . . . . 126. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 137. Security Considerations . . . . . . . . . . . . . . . . . . . 138. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 149. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 1410. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 10.1. Normative References . . . . . . . . . . . . . . . . . . . 15 10.2. Informative References . . . . . . . . . . . . . . . . . . 15 Appendix A. Using Tunnel Mode . . . . . . . . . . . . . . . . . . 17 A.1. Tunnel Mode Implementation Methods . . . . . . . . . . . . 17 A.2. Specific SPD for Host-to-Host Scenario . . . . . . . . . . 18 A.3. Specific SPD for Host-to-Router Scenario . . . . . . . . . 19 Appendix B. Optional Features . . . . . . . . . . . . . . . . . . 20 B.1. Dynamic Address Configuration . . . . . . . . . . . . . . 20 B.2. NAT Traversal and Mobility . . . . . . . . . . . . . . . . 20 B.3. Tunnel Endpoint Discovery . . . . . . . . . . . . . . . . 21 Graveman, et al. Informational [Page 2]1. IntroductionThe IPv6 Operations (v6ops) working group has selected (manuallyconfigured) IPv6-in-IPv4 tunneling [RFC4213] as one of the IPv6transition mechanisms for IPv6 deployment.[RFC4213] identified a number of threats that had not been adequately analyzed or addressed in its predecessor [RFC2893]. The mostcomplete solution is to use IPsec to protect IPv6-in-IPv4 tunneling. The document was intentionally not expanded to include the details on how to set up an IPsec-protected tunnel in an interoperable manner,but instead the details were deferred to this memo.The first four sections of this document analyze the threats andscenarios that can be addressed by IPsec and assumptions made by this document for successful IPsec Security Association (SA)establishment. Section 5 gives the details of Internet Key Exchange (IKE) and IP security (IPsec) exchange with packet formats andSecurity Policy Database (SPD) entries. Section 6 givesrecommendations. Appendices further discuss tunnel mode usage andoptional extensions.This document does not address the use of IPsec for tunnels that are not manually configured (e.g., 6to4 tunnels [RFC3056]). Presumably, some form of opportunistic encryption or "better-than-nothingsecurity" might or might not be applicable. Similarly, propagatingquality-of-service attributes (apart from Explicit CongestionNotification bits [RFC4213]) from the encapsulated packets to thetunnel path is out of scope.The use of the word "interface" or the phrase "IP interface" refersto the IPv6 interface that must be present on any IPv6 node to sendor receive IPv6 packets. The use of the phrase "tunnel interface"refers to the interface that receives the IPv6-in-IPv4 tunneledpackets over IPv4.2. Threats and the Use of IPsec[RFC4213] is mostly concerned about address spoofing threats:1. The IPv4 source address of the encapsulating ("outer") packet can be spoofed.2. The IPv6 source address of the encapsulated ("inner") packet can be spoofed.Graveman, et al. Informational [Page 3]The reason threat (1) exists is the lack of universal deployment ofIPv4 ingress filtering [RFC3704]. The reason threat (2) exists isthat the IPv6 packet is encapsulated in IPv4 and hence may escapeIPv6 ingress filtering. [RFC4213] specifies the following strictaddress checks as mitigating measures:o To mitigate threat (1), the decapsulator verifies that the IPv4source address of the packet is the same as the address of theconfigured tunnel endpoint. The decapsulator may also implementIPv4 ingress filtering, i.e., check whether the packet is received on a legitimate interface.o To mitigate threat (2), the decapsulator verifies whether theinner IPv6 address is a valid IPv6 address and also applies IPv6ingress filtering before accepting the IPv6 packet.This memo proposes using IPsec for providing stronger security inpreventing these threats and additionally providing integrity,confidentiality, replay protection, and origin protection betweentunnel endpoints.IPsec can be used in two ways, in transport and tunnel mode; detailed discussion about applicability in this context is provided inSection 5.2.1. IPsec in Transport ModeIn transport mode, the IPsec Encapsulating Security Payload (ESP) or Authentication Header (AH) security association (SA) is establishedto protect the traffic defined by (IPv4-source, IPv4-dest, protocol = 41). On receiving such an IPsec packet, the receiver first appliesthe IPsec transform (e.g., ESP) and then matches the packet againstthe Security Parameter Index (SPI) and the inbound selectorsassociated with the SA to verify that the packet is appropriate forthe SA via which it was received. A successful verification implies that the packet came from the right IPv4 endpoint, because the SA is bound to the IPv4 source address.This prevents threat (1) but not threat (2). IPsec in transport mode does not verify the contents of the payload itself where the IPv6addresses are carried. That is, two nodes using IPsec transport mode to secure the tunnel can spoof the inner payload. The packet will be decapsulated successfully and accepted.This shortcoming can be partially mitigated by IPv6 ingressfiltering, i.e., check that the packet is arriving from the interface in the direction of the route towards the tunnel endpoint, similar to a Strict Reverse Path Forwarding (RPF) check [RFC3704].Graveman, et al. Informational [Page 4]In most implementations, a transport mode SA is applied to a normalIPv6-in-IPv4 tunnel. Therefore, ingress filtering can be applied in the tunnel interface. (Transport mode is often also used in otherkinds of tunnels such as Generic Routing Encapsulation (GRE)[RFC4023] and Layer 2 Tunneling Protocol (L2TP) [RFC3193].)2.2. IPsec in Tunnel ModeIn tunnel mode, the IPsec SA is established to protect the trafficdefined by (IPv6-source, IPv6-destination). On receiving such anIPsec packet, the receiver first applies the IPsec transform (e.g.,ESP) and then matches the packet against the SPI and the inboundselectors associated with the SA to verify that the packet isappropriate for the SA via which it was received. The successfulverification implies that the packet came from the right endpoint.The outer IPv4 addresses may be spoofed, and IPsec cannot detect this in tunnel mode; the packets will be demultiplexed based on the SPIand possibly the IPv6 address bound to the SA. Thus, the outeraddress spoofing is irrelevant as long as the decryption succeeds and the inner IPv6 packet can be verified to have come from the righttunnel endpoint.As described in Section 5, using tunnel mode is more difficult thanapplying transport mode to a tunnel interface, and as a result thisdocument recommends transport mode. Note that even though transport rather than tunnel mode is recommended, an IPv6-in-IPv4 tunnelspecified by protocol 41 still exists [RFC4213].3. Scenarios and OverviewThere are roughly three scenarios:1. (Generic) router-to-router tunnels.2. Site-to-router or router-to-site tunnels. These refer to tunnels between a site’s IPv6 (border) device and an IPv6 upstreamprovider’s router. A degenerate case of a site is a single host.3. Host-to-host tunnels.Graveman, et al. Informational [Page 5]3.1. Router-to-Router TunnelsIPv6/IPv4 hosts and routers can tunnel IPv6 datagrams over regions of IPv4 forwarding topology by encapsulating them within IPv4 packets.Tunneling can be used in a variety of ways..--------. _----_ .--------.|v6-in-v4| _( IPv4 )_ |v6-in-v4|| Router | <======( Internet )=====> | Router || A | (_ _) | B |’--------’ ’----’ ’--------’^ IPsec tunnel between ^| Router A and Router B |V VFigure 1: Router-to-Router Scenario.IPv6/IPv4 routers interconnected by an IPv4 infrastructure can tunnel IPv6 packets between themselves. In this case, the tunnel spans one segment of the end-to-end path that the IPv6 packet takes.The source and destination addresses of the IPv6 packets traversingthe tunnel could come from a wide range of IPv6 prefixes, so binding IPv6 addresses to be used to the SA is not generally feasible. IPv6 ingress filtering must be performed to mitigate the IPv6 addressspoofing threat.A specific case of router-to-router tunnels, when one router resides at an end site, is described in the next section.3.2. Site-to-Router/Router-to-Site TunnelsThis is a generalization of host-to-router and router-to-hosttunneling, because the issues when connecting a whole site (using arouter) and connecting a single host are roughly equal.Graveman, et al. Informational [Page 6]_----_ .---------. IPsec _----_ IPsec .-------._( IPv6 )_ |v6-in-v4 | Tunnel _( IPv4 )_ Tunnel | V4/V6 |( Internet )<--->| Router |<=======( Internet )=======>| Site B |(_ _) | A | (_ _) ’--------’’----’ ’---------’ ’----’^|V.--------.| Native || IPv6 || node |’--------’Figure 2: Router-to-Site Scenario.IPv6/IPv4 routers can tunnel IPv6 packets to their final destination IPv6/IPv4 site. This tunnel spans only the last segment of the end- to-end path.+---------------------+| IPv6 Network || |.--------. _----_ | .--------. || V6/V4 | _( IPv4 )_ | |v6-in-v4| || Site B |<====( Internet )==========>| Router | |’--------’ (_ _) | | A | |’----’ | ’--------’ |IPsec tunnel between | ^ |IPv6 Site and Router A | | || V || .-------. || | V6 | || | Hosts | || ’--------’ |+---------------------+Figure 3: Site-to-Router Scenario.In the other direction, IPv6/IPv4 hosts can tunnel IPv6 packets to an intermediary IPv6/IPv4 router that is reachable via an IPv4infrastructure. This type of tunnel spans the first segment of thepacket’s end-to-end path.The hosts in the site originate the packets with IPv6 sourceaddresses coming from a well-known prefix, whereas the destinationaddresses could be any nodes on the Internet.Graveman, et al. Informational [Page 7]In this case, an IPsec tunnel mode SA could be bound to the prefixthat was allocated to the router at Site B, and Router A could verify that the source address of the packet matches the prefix. Site Bwill not be able to do a similar verification for the packets itreceives. This may be quite reasonable for most of the deploymentcases, for example, an Internet Service Provider (ISP) allocating a/48 to a customer. The Customer Premises Equipment (CPE) where thetunnel is terminated "trusts" (in a weak sense) the ISP’s router, and the ISP’s router can verify that Site B is the only one that canoriginate packets within the /48.IPv6 spoofing must be prevented, and setting up ingress filtering may require some amount of manual configuration; see more of theseoptions in Section 5.3.3. Host-to-Host Tunnels.--------. _----_ .--------.| V6/V4 | _( IPv4 )_ | V6/V4 || Host | <======( Internet )=====> | Host || A | (_ _) | B |’--------’ ’----’ ’--------’IPsec tunnel betweenHost A and Host BFigure 4: Host-to-Host Scenario.IPv6/IPv4 hosts interconnected by an IPv4 infrastructure can tunnelIPv6 packets between themselves. In this case, the tunnel spans the entire end-to-end path.In this case, the source and the destination IPv6 addresses are known a priori. A tunnel mode SA could be bound to these specificaddresses. Address verification prevents IPv6 source addressspoofing completely.As noted in the Introduction, automatic host-to-host tunnelingmethods (e.g., 6to4) are out of scope for this memo.Graveman, et al. Informational [Page 8]4. IKE and IPsec VersionsThis section discusses the different versions of the IKE and IPsecsecurity architecture and their applicability to this document.The IPsec security architecture was previously defined in [RFC2401]and is now superseded by [RFC4301]. IKE was originally defined in[RFC2409] (which is called IKEv1 in this document) and is nowsuperseded by [RFC4306] (called IKEv2; see also [RFC4718]). Thereare several differences between them. The differences relevant tothis document are discussed below.1. [RFC2401] does not require allowing IP as the next layer protocol in traffic selectors when an IPsec SA is negotiated. Incontrast, [RFC4301] requires supporting IP as the next layerprotocol (like TCP or UDP) in traffic selectors.2. [RFC4301] assumes IKEv2, as some of the new features cannot benegotiated using IKEv1. It is valid to negotiate multipletraffic selectors for a given IPsec SA in [RFC4301]. This ispossible only with IKEv2. If IKEv1 is used, then multiple SAsneed to be set up, one for each traffic selector.Note that the existing implementations based on IKEv1 may already be able to support the [RFC4301] features described in (1) and (2). If appropriate, the deployment may choose to use either version of thesecurity architecture.IKEv2 supports features useful for configuring and securing tunnelsnot present with IKEv1.1. IKEv2 supports legacy authentication methods by carrying them in Extensible Authentication Protocol (EAP) payloads. This can beused to authenticate hosts or sites to an ISP using EAP methodsthat support username and password.2. IKEv2 supports dynamic address configuration, which may be usedto configure the IPv6 address of the host.Network Address Translation (NAT) traversal works with both the oldand revised IPsec architectures, but the negotiation is integratedwith IKEv2.For the purposes of this document, where the confidentiality of ESP[RFC4303] is not required, AH [RFC4302] can be used as an alternative to ESP. The main difference is that AH is able to provide integrity protection for certain fields in the outer IPv4 header and IPv4options. However, as the outer IPv4 header will be discarded in any Graveman, et al. Informational [Page 9]case, and those particular fields are not believed to be relevant in this particular application, there is no particular reason to use AH.5. IPsec Configuration DetailsThis section describes the SPD entries for setting up the IPsectransport mode SA to protect the IPv6 traffic.Several requirements arise when IPsec is used to protect the IPv6traffic (inner header) for the scenarios listed in Section 3.1. All of IPv6 traffic should be protected, including link-local(e.g., Neighbor Discovery) and multicast traffic. Without this, an attacker can pollute the IPv6 neighbor cache causingdisruption in communication between the two routers.2. In router-to-router tunnels, the source and destination addresses of the traffic could come from a wide range of prefixes that are normally learned through routing. As routing can always learn a new prefix, one cannot assume that all the prefixes are known apriori [RFC3884]. This mainly affects scenario (1).3. Source address selection depends on the notions of routes andinterfaces. This implies that the reachability to the variousIPv6 destinations appear as routes in the routing table. Thisaffects scenarios (2) and (3).The IPv6 traffic can be protected using transport or tunnel mode.There are many problems when using tunnel mode as implementations may or may not model the IPsec tunnel mode SA as an interface asdescribed in Appendix A.1.If IPsec tunnel mode SA is not modeled as an interface (e.g., as ofthis writing, popular in many open source implementations), the SPDentries for protecting all traffic between the two endpoints must be described. Evaluating against the requirements above, all link-local traffic multicast traffic would need to be identified, possiblyresulting in a long list of SPD entries. The second requirement isdifficult to satisfy, because the traffic needing protection is notnecessarily (e.g., router-to-router tunnel) known a priori [RFC3884]. The third requirement is also problematic, because almost allimplementations assume addresses are assigned on interfaces (ratherthan configured in SPDs) for proper source address selection.If the IPsec tunnel mode SA is modeled as interface, the traffic that needs protection can be modeled as routes pointing to the interface. But the second requirement is difficult to satisfy, because thetraffic needing protection is not necessarily known a priori. The Graveman, et al. Informational [Page 10]third requirement is easily solved, because IPsec is modeled as aninterface.In practice, (2) has been solved by protecting all the traffic(::/0), but no interoperable implementations support this feature.For a detailed list of issues pertaining to this, see [VLINK].Because applying transport mode to protect a tunnel is a much simpler solution and also easily protects link-local and multicast traffic,we do not recommend using tunnel mode in this context. Tunnel modeis, however, discussed further in Appendix A.This document assumes that tunnels are manually configured on bothsides and the ingress filtering is manually set up to discard spoofed packets.5.1. IPsec Transport ModeTransport mode has typically been applied to L2TP, GRE, and othertunneling methods, especially when the user wants to tunnel non-IPtraffic. [RFC3884], [RFC3193], and [RFC4023] provide examples ofapplying transport mode to protect tunnel traffic that spans only apart of an end-to-end path.IPv6 ingress filtering must be applied on the tunnel interface on all the packets that pass the inbound IPsec processing.The following SPD entries assume that there are two routers, Router1 and Router2, with tunnel endpoint IPv4 addresses denoted IPV4-TEP1and IPV4-TEP2, respectively. (In other scenarios, the SPDs are setup similarly.)Router1’s SPD:Next LayerRule Local Remote Protocol Action---- ----- ------ ---------- --------1 IPV4-TEP1 IPV4-TEP2 ESP BYPASS2 IPV4-TEP1 IPV4-TEP2 IKE BYPASS3 IPv4-TEP1 IPV4-TEP2 41 PROTECT(ESP,transport) Graveman, et al. Informational [Page 11]Router2’s SPD:Next LayerRule Local Remote Protocol Action---- ----- ------ ---------- --------1 IPV4-TEP2 IPV4-TEP1 ESP BYPASS2 IPV4-TEP2 IPV4-TEP1 IKE BYPASS3 IPv4-TEP2 IPV4-TEP1 41 PROTECT(ESP,transport)In both SPD entries, "IKE" refers to UDP destination port 500and possibly also port 4500 if NAT traversal is used.The packet format is as shown in Table 1.+----------------------------+------------------------------------+ | Components (first to last) | Contains | +----------------------------+------------------------------------+ | IPv4 header | (src = IPV4-TEP1, dst = IPV4-TEP2) | | ESP header | | | IPv6 header | (src = IPV6-EP1, dst = IPV6-EP2) | | (payload) | | +----------------------------+------------------------------------+ Table 1: Packet Format for IPv6/IPv4 Tunnels.The IDci and IDcr payloads of IKEv1 carry the IPv4-TEP1, IPV4-TEP2,and protocol value 41 as phase 2 identities. With IKEv2, the traffic selectors are used to carry the same information.5.2. Peer Authorization Database and IdentitiesThe Peer Authorization Database (PAD) provides the link between SPDand the key management daemon [RFC4306]. This is defined in[RFC4301] and hence relevant only when used with IKEv2.As there is currently no defined way to discover the PAD-relatedparameters dynamically, it is assumed that these are manuallyconfigured:o The Identity of the peer asserted in the IKEv2 exchange: Manydifferent types of identities can be used. At least, the IPv4address of the peer should be supported.o IKEv2 can authenticate the peer by several methods. Pre-sharedkey and X.509 certificate-based authentication is required by[RFC4301]. At least, pre-shared key should be supported, because it interoperates with a larger number of implementations. Graveman, et al. Informational [Page 12]o The child SA authorization data should contain the IPv4 address of the peer.IPv4 address should be supported as Identity during the key exchange. As this does not provide Identity protection, main mode or aggressive mode can be used with IKEv1.6. RecommendationsIn Section 5, we examined the differences between setting up an IPsec IPv6-in-IPv4 tunnel using either transport or tunnel mode. Weobserve that applying transport mode to a tunnel interface is thesimplest and therefore recommended solution.In Appendix A, we also explore what it would take to use so-calledSpecific SPD (SSPD) tunnel mode. Such usage is more complicatedbecause IPv6 prefixes need to be known a priori, and multicast andlink-local traffic do not work over such a tunnel. Fragment handling in tunnel mode is also more difficult. However, because the Mobility and Multihoming Protocol (MOBIKE) [RFC4555] supports only tunnelmode, when the IPv4 endpoints of a tunnel are dynamic and the otherconstraints are not applicable, using tunnel mode may be anacceptable solution.Therefore, our primary recommendation is to use transport modeapplied to a tunnel interface. Source address spoofing can belimited by enabling ingress filtering on the tunnel interface.Manual keying must not be used as large amounts of IPv6 traffic maybe carried over the tunnels and doing so would make it easier for an attacker to recover the keys. IKEv1 or IKEv2 must be used forestablishing the IPsec SAs. IKEv2 should be used where supported and available; if not, IKEv1 may be used instead.7. Security ConsiderationsWhen running IPv6-in-IPv4 tunnels (unsecured) over the Internet, itis possible to "inject" packets into the tunnel by spoofing thesource address (data plane security), or if the tunnel is signaledsomehow (e.g., using authentication protocol and obtaining a staticv6 prefix), someone might be able to spoof the signaling (controlplane security).The IPsec framework plays an important role in adding security toboth the protocol for tunnel setup and data traffic.Either IKEv1 or IKEv2 provides a secure signaling protocol forestablishing, maintaining, and deleting an IPsec tunnel.Graveman, et al. Informational [Page 13]IPsec, with ESP, offers integrity and data origin authentication,confidentiality, and optional (at the discretion of the receiver)anti-replay features. Using confidentiality without integrity isdiscouraged. ESP furthermore provides limited traffic flowconfidentiality.IPsec provides access control mechanisms through the distribution of keys and also through the application of policies dictated by theSecurity Policy Database (SPD).The NAT traversal mechanism provided by IKEv2 introduces someweaknesses into IKE and IPsec. These issues are discussed in moredetail in [RFC4306].Please note that using IPsec for the scenarios described in Figures1, 2, and 3 does not aim to protect the end-to-end communication. It protects just the tunnel part. It is still possible for an IPv6endpoint not attached to the IPsec tunnel to spoof packets.8. ContributorsThe authors are listed in alphabetical order.Suresh Satapati also participated in the initial discussions on this topic.9. AcknowledgmentsThe authors would like to thank Stephen Kent, Michael Richardson,Florian Weimer, Elwyn Davies, Eric Vyncke, Merike Kaeo, AlfredHoenes, Francis Dupont, and David Black for their substantivefeedback.We would like to thank Pasi Eronen for his text contributions andsuggestions for improvement.Graveman, et al. Informational [Page 14]10. References10.1. Normative References[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for theInternet Protocol", RFC 2401, November 1998.[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange(IKE)", RFC 2409, November 1998.[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004.[RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. Stenberg, "UDP Encapsulation of IPsec ESP Packets",RFC 3948, January 2005.[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers", RFC 4213, October 2005.[RFC4301] Kent, S. and K. Seo, "Security Architecture for theInternet Protocol", RFC 4301, December 2005.[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",RFC 4303, December 2005.[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",RFC 4306, December 2005.10.2. Informative References[RFC2893] Gilligan, R. and E. Nordmark, "Transition Mechanisms forIPv6 Hosts and Routers", RFC 2893, August 2000.[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domainsvia IPv4 Clouds", RFC 3056, February 2001.[RFC3193] Patel, B., Aboba, B., Dixon, W., Zorn, G., and S. Booth,"Securing L2TP using IPsec", RFC 3193, November 2001.[RFC3715] Aboba, B. and W. Dixon, "IPsec-Network Address Translation (NAT) Compatibility Requirements", RFC 3715, March 2004.[RFC3884] Touch, J., Eggert, L., and Y. Wang, "Use of IPsecTransport Mode for Dynamic Routing", RFC 3884,September 2004.Graveman, et al. Informational [Page 15][RFC4023] Worster, T., Rekhter, Y., and E. Rosen, "EncapsulatingMPLS in IP or Generic Routing Encapsulation (GRE)",RFC 4023, March 2005.[RFC4302] Kent, S., "IP Authentication Header", RFC 4302,December 2005.[RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol(MOBIKE)", RFC 4555, June 2006.[RFC4718] Eronen, P. and P. Hoffman, "IKEv2 Clarifications andImplementation Guidelines", RFC 4718, October 2006.[TUNN-AD] Palet, J. and M. Diaz, "Analysis of IPv6 Tunnel End-point Discovery Mechanisms", Work in Progress, January 2005.[VLINK] Duffy, M., "Framework for IPsec Protected Virtual Linksfor PPVPNs", Work in Progress, October 2002.Graveman, et al. Informational [Page 16]。
IPV6隧道配置
IPv6隧道配置一、概述IPv6的根本目的是继承和取代IPv4，但从IPv4到IPv6的演进是一个逐渐的过程。
因此在IPv6完全取代IPv4之前，不可避免地，这两种协议要有一个共存时期。
在这个过渡阶段的初期，IPv4网络仍然是主要的网络，IPv6网络类似孤立于IPv4网络中的小岛。
过渡的问题可以分成两大类：1)被孤立的IPv6网络之间透过IPv4网络互相通信的问题；2) IPv6的网络与IPv4网络之间通信的问题；本文讨论的隧道（Tunnel）技术，就是解决问题1的，解决问题2的方案是NAT-PT（网络地址转换-协议转换），不在本文讨论范围内。
IPv6隧道是将IPv6报文封装在IPv4报文中，这样IPv6协议包就可以穿越IPv4网络进行通信。
因此被孤立的IPv6网络之间可以通过IPv6的隧道技术利用现有的IPv4网络互相通信而无需对现有的IPv4网络做任何修改和升级。
IPv6隧道可以配置在边界路由器之间也可以配置在边界路由器和主机之间，但是隧道两端的节点都必须既支持IPv4协议栈又支持IPv6协议栈。
注意：通过IPv6隧道技术将被孤立的IPv6网络互联起来并不是最终的IPv6的网络架构，而只是一种过渡的技术。
使用隧道技术的模型如下图：1手工配置隧道(IPv6 Manually Configured Tunnel)一个手工配置隧道类似于在两个IPv6域之间通过IPv4的主干网络建立了一条永久链路。
适合用在两台边界路由器或者边界路由器和主机之间对安全性要求较高并且比较固定的连接上。
在隧道接口上，IPv6地址需要手工配置，并且隧道的源IPv4地址(Tunnel Source)和目的IPv4地址(Tunnel Destination)必须手工配置。
隧道两端的节点必须支持IPv6和IPv4协议栈。
手工配置隧道在实际应用中总是成对配置的，即在两台边缘设备上同时配置，可以将其看作是一种点对点的隧道。
26to4自动隧道(Automatic 6to4 Tunnel)6to4自动隧道技术允许将被孤立的IPv6网络透过IPv4网络互联。
ipv4转换ipv6的方法
IPv4转换IPv6的方法1. 介绍IPv4（Internet Protocol version 4）是互联网上广泛使用的IP协议版本，它使用32位地址来标识网络上的设备。
然而，由于互联网的迅速发展和设备数量的增加，IPv4地址资源已经日益紧缺。
为了解决这个问题，IPv6（Internet Protocol version 6）被提出并逐渐推广。
IPv6采用128位地址，相比于IPv4拥有更大的地址空间。
为了实现从IPv4向IPv6的过渡，需要将现有的IPv4地址转换成IPv6格式。
本文将详细介绍几种常见的IPv4转换IPv6的方法。
2. IPv4与IPv6地址格式比较IPv4地址由四个以点分隔的十进制数表示，每个数值范围从0到255（例如：192.168.0.1）。
而IPv6地址由八组以冒号分隔的十六进制数表示，每个数值范围从0到FFFF（例如：2001:0db8:85a3:0000:0000:8a2e:0370:7334）。
3. IPv4转换为IPv6方法3.1 纯文本表示法（Text Representation）纯文本表示法是一种简单直观的方式，将每个组件拆分为四个字符，并在每个组件之间插入两个冒号。
例如，IPv4地址192.0.2.1可以转换为IPv6地址::ffff:192.0.2.1。
3.2 网络前缀表示法（Prefix Notation）网络前缀表示法将IPv4地址与IPv6前缀相结合，创建一个新的IPv6地址。
这种方法将IPv4地址的前32位作为IPv6地址的前缀，后96位保持不变。
例如，IPv4地址192.0.2.1可以转换为IPv6地址::ffff:192.0.2.1/96。
3.3 IPv4映射的IPv6地址（IPv4-mapped IPv6 Address）这种方法使用特殊的前缀和后缀来表示IPv4映射的IPv6地址。
它将32位的IPv4地址嵌入到128位的IPv6地址中，并在前面添加特殊的前缀（::ffff:0:0/96）。
IPv6测试综述
摘要：随着Internet 的迅速增长以及IPv4地址空间的逐渐耗尽，对新型因特网协议的需要已成为网络业界所充分认识并普遍接受。
更多的地址空间、IP 层上更简单的地址设计与处理、更好的QoS 支持、更强的安全性、更多的媒体类型与使用因特网的设备，种种需要均推动着因特网协议第6版(IPv6)的发展。
文章指出IPv6测试的关键范围，并以Ixia 的测试为例介绍了每种测试的适当测试方法。
关键词：IPv6；一致性；扩展性IPv6测试综述钟兴(中国铁通总部设备维护中心)收稿日期：2009-10-30IPv4是全球通用因特网协议的当前版本。
事实证明，该版本稳固耐用、便于实施、且能够与多种协议及应用设备良好协同。
IPv4自20世纪80年代初首次确立以来几乎未曾改动，但其始终支持因特网的升迁，一直发展到目前的全球规模。
然而随着因特网与因特网服务不断发展，IPv4在因特网的目前规模与复杂性面前已暴露其不足。
IPv6是专为弥补这些不足而开发的，以便让因特网能够进一步发展壮大。
可以预见，IPv6充裕的（128位）地址空间为支持因特网的预期增长与发展提供了足够数量的全球唯一地址。
1为什么要测试IPv6技术？通过测试确保协同能力：IPv6初期部署的诸多障碍不仅包括IPv6与IPv4系统之间的协同能力，而且还包括在不同厂商设备之间的协同能力。
在部署IPv6之前查找和排除问题的测试工具是运营商们不容忽视的关键需要。
对NEM 而言，提供可协同的产品是引进任何新技术获得成功的关键要素。
要解决对原有IPv4基础设施与众多厂商的IPv6系统之间存在的协同问题上的担忧，就只有通过全面测试方法来确保其协同能力。
IPv6是由超过60个IETF RFC 定义的技术。
实施甚为庞大与复杂的RFC 极易发生误会与曲解。
采取全面、严格的测试方法进行一致性测试有助于提高产品质量、加强客户信心。
一致性测试还使厂商能够在整个产品寿命周期中对产品设计进行验证，从而节省了时间与财力。
rfc5569.IPv6 Rapid Deployment on IPv4 Infrastructures (6rd)
Independent Submission R. Despres Request for Comments: 5569 RD-IPtech Category: Informational January 2010 ISSN: 2070-1721IPv6 Rapid Deployment on IPv4 Infrastructures (6rd)AbstractIPv6 rapid deployment on IPv4 infrastructures (6rd) builds uponmechanisms of 6to4 to enable a service provider to rapidly deployIPv6 unicast service to IPv4 sites to which it provides customerpremise equipment. Like 6to4, it utilizes stateless IPv6 in IPv4encapsulation in order to transit IPv4-only network infrastructure.Unlike 6to4, a 6rd service provider uses an IPv6 prefix of its own in place of the fixed 6to4 prefix. A service provider has used thismechanism for its own IPv6 "rapid deployment": five weeks from first exposure to 6rd principles to more than 1,500,000 residential sitesbeing provided native IPv6, under the only condition that theyactivate it.Status of This MemoThis document is not an Internet Standards Track specification; it is published for informational purposes.This is a contribution to the RFC Series, independently of anyother RFC stream. The RFC Editor has chosen to publish thisdocument at its discretion and makes no statement about its valuefor implementation or deployment. Documents approved forpublication by the RFC Editor are not a candidate for any level ofInternet Standard; see Section 2 of RFC 5741.Information about the current status of this document, anyerrata, and how to provide feedback on it may be obtained at/info/rfc5569.Despres Informational [Page 1]Copyright NoticeCopyright (c) 2010 IETF Trust and the persons identified asthe document authors. All rights reserved.This document is subject to BCP 78 and the IETF Trust’s LegalProvisions Relating to IETF Documents(http:/license-info) in effect on the date ofpublication of this document. Please review these documentscarefully, as they describe your rights and restrictions with respect to this document.Table of Contents1. Introduction (2)2. Problem Statement and Purpose of 6rd (3)3. Specification (4)4. Applicability to ISPs That Assign Private IPv4 Addresses (7)5. Security Considerations (8)6. IANA Considerations (8)7. Acknowledgements (9)8. References (9)8.1. Normative References (9)8.2. Informative References (9)1. IntroductionAfter having had a succinct presentation of the 6rd idea, a majorFrench Internet service provider (ISP), Free of the Iliad group(hereafter Free), did all of the following in an impressively shortdelay of only five weeks (November 7th to December 11th 2007):1. obtained from its regional Internet Registry (RIR) an IPv6prefix, the length of which was that allocated without ajustification and a delay to examine it, namely /32;2. added 6rd support to the software of its Freebox home-gateway(upgrading for this an available 6to4 code);3. provisioned PC-compatible platform with a 6to4 gateway software;4. modified it to support 6rd;5. tested IPv6 operation with several operating systems andapplications;6. finished operational deployment, by means of new version of thedownloadable software of their Freeboxes;Despres Informational [Page 2]7. announced IPv6 Internet connectivity, at no extra charge, for all its customers wishing to activate it.More than 1,500,000 residential customers thus became able to useIPv6 if they wished, with all the look and feel of native IPv6addresses routed in IPv6. The only condition was an activation ofIPv6 in their Freeboxes, and of course in their IPv6-capable hosts.This story is reported to illustrate that ISPs that provide customer premise equipment (CPE) to their clients, with included routingcapability, and that have so far postponed IPv6 deployment can, with the dramatically reduced investment and operational costs that 6rdmake possible, decide to wait no longer.To complete the story, Free announced, on March 6th 2008, thatprovided two of its customer sites had IPv6 activated, its Telesites application (Web sites published on TV) could now be used remotelybetween them.While IPv6 availability was limited in December 2007 to only one IPv6 link per customer site (with /64 site-prefix assignments). A fewmonths later, after Free had detailed its achievement and plans toits RIR, and then obtained from it a /26 prefix, up to 16 IPv6 links per customer became possible (with /60 site-prefix assignments).Readers are supposed to be familiar with 6to4 [RFC3056].2. Problem Statement and Purpose of 6rdHaving ISPs to rapidly bring IPv6 to customers’ sites, in addition to IPv4 and without extra charge, is a way to break the existing vicious circle that has delayed IPv6 deployment: ISPs wait for customerdemand before deploying IPv6; customers don’t demand IPv6 as long as application vendors announce that their products work on existinginfrastructures (that are IPv4 with NATs); application vendors focus their investments on NAT traversal compatibility as long as ISPsdon’t deploy IPv6.But most ISPs are not willing to add IPv6 to their current offer atno charge unless incurred investment and operational costs areextremely limited. For this, ISPs that provide router CPEs to their customers have the most favorable conditions: they can upgrade their router CPEs and can operate gateways between their IPv4infrastructures and the global IPv6 Internet to support IPv6encapsulation in IPv4. They then need no more routing plans thanthose that exist on these IPv4 infrastructures.Despres Informational [Page 3]Encapsulation a la 6to4, as specified in [RFC3056], is very close to being sufficient for this: it is simple; it is supported on manyplatforms including PC-compatible appliances; open-source portablecode is available; its stateless nature ensures good scalability.There is however a limitation of 6to4 that prevents ISPs from usingit to offer full IPv6 unicast connectivity to their customers. While an ISP that deploys 6to4 can guarantee that IPv6 packets outgoingfrom its customer sites will reach the IPv6 Internet, and alsoguarantee that packets coming from other 6to4 sites will reach itscustomer sites, it cannot guarantee that packets from native IPv6sites will reach them. The problem is that a packet coming from anative IPv6 address needs to traverse, somewhere on its way, a 6to4relay router to do the required IPv6/IPv4 encapsulation. There is no guarantee that routes toward such a relay exist from everywhere, nor is there a guarantee that all such relays do forward packets towardthe complete IPv4 Internet.Also, if an ISP operates one or several 6to4 relay routers and opens IPv6 routes toward them in the IPv6 Internet, for the 6to4 prefix2002::/16, it may receive in these relays packets destined to anunknown number of other 6to4 ISPs. If it doesn’t forward thesepackets, it creates a black hole in which packets may besystematically lost, breaking some of the IPv6 connectivity. If itdoes forward them, it can no longer dimension its 6to4 relay routers in proportion to the traffic of its own customers. Quality ofservice, at least for customers of other 6to4 ISPs, will then hardly be guaranteed.The purpose of 6rd is to slightly modify 6to4 so that:1. Packets that, coming from the global Internet, enter 6rd gateways of an ISP are only packets destined to customer sites of thisISP.2. All IPv6 packets destined to 6rd customer sites of an ISP, andcoming from anywhere else on the IPv6 Internet, traverse a 6rdgateway of this ISP.3. SpecificationThe principle of 6rd is that, to build on 6to4 and suppress itslimitation, it is sufficient that:1. 6to4 functions are modified to replace the standard 6to4 prefix2002::/16 by an IPv6 prefix that belongs to the ISP-assignedaddress space, and to replace the 6to4 anycast address by another anycast address chosen by the ISP.Despres Informational [Page 4]2. The ISP operates one or several 6rd gateways (upgraded 6to4routers) at its border between its IPv4 infrastructure and theIPv6 Internet.3. CPEs support IPv6 on their customer-site side and support 6rd(upgraded 6to4 function) on their provider side.Figure 1 shows how the IPv6 prefix of a customer site is derived from its IPv4 address.+---------------//-------.------------------------------+ | 6rd-relays IPv6 prefix | IPv4 address | | of the ISP | of the customer site | +---------------//-------’------------------------------+ <-- less or equal to 32 -><------------ 32 -------------> <-- less or equal to 64 ------------------------------->Figure 1: Format of the IPv6 Prefix Assigned to a 6rd Customer SiteFigure 2 shows which nodes have to be upgraded from 6to4 to 6rd, and which addresses or prefixes have to be routed to them.IPv4 AND IPv6 customer site|| 6rd CPEs 6rd relays| (modified 6to4) (modified 6to4)| | || | __________________________ || | | | || | | ISP IPV4 INFRASTRUCTURE | V GLOBALV V | | ___ IPV6___ | | | | INTERNET| | | | .-----------------|--| |---|--| |--|-. / | |___|| |___| | \ / || \ / IPv4 | IPv6 Prefix| O anycast address => | <= of 6rd relays| ___ | / \ of 6rd relays | of the ISP| | | | / \ | ___|--| |--|-’ \ | | || |___| | ’-----------------|--| |---| | | |___|| IPv4 addresses || <= of customer sites ||__________________________|Figure 2: ISP Architecture to Deploy IPv6 with 6rdDespres Informational [Page 5]NOTE: The chosen address format uses 32 bits of IPv4 addresses inIPv6 addresses for reasons of simplicity and of compatibility withthe existing 6to4 code. Limiting initially Free’s customer sites to one IPv6 subnet per site, a consequence of Free’s initial prefixbeing a /32, was not a significant restriction: since Free’scustomers are essentially residential, most of them would have beenunable to use several subnets anyway, and as soon as Free would get a prefix shorter than /32, this restriction would be relaxed. If ithad been important to immediately use less than 32 bits of IPv4addresses in IPv6 prefixes, this would have been possible. SinceFree, like many ISPs, had several RIR-allocated IPv4 prefixes (6 ofthem, having lengths from /10 to /16 in the particular case), 6rdgateways and 6rd CPEs could for this have implemented variable-length mapping table. But some of the IPv4 addressing entropy would thushave been extended to 6rd gateways and CPEs. Complexity being thensignificantly higher, this would have defeated the objective ofextreme simplicity to favor actual and rapid deployment.IPv6 communication between customer sites of a same ISP is directacross the ISP IPv4 infrastructure: when a CPE sees that the IPv6destination address of an outgoing packet starts with its own 6rdrelay ISPv6 prefix, it takes the 32 bits that follow this prefix asIPv4 destination of the encapsulating packet. (Sending anddecapsulation rules of 6to4, duly adapted to the 6rd prefix in place of the 6to4 prefix, apply as described in Section 5.3 of [RFC3056].) The IPv4 anycast address of 6rd relays may be chosen independently by each ISP. The only constraint is that routes toward the ISP that are advertised must not include this address. For example, Free took a192.88.99.201 address, routed with the same /24 prefix as 6to4 butwith 201 instead of 1 to avoid confusion with 192.88.99.1, the 6to4anycast address of [RFC3068]. Another possibility, not retained,would have been to use the anycast address of 6to4 and to add, inrelays, a test on the IPv6 prefix of the ISP-side address. If itstarts with 2002::/16, the packet is 6to4, not 6rd.Despres Informational [Page 6]4. Applicability to ISPs That Assign Private IPv4 Addresses______________________________| || 10.x.x.x/8 private addresses || <== |<-----| IPv4 anycast address |----->| of 6rd relays |6rd-CPEs | ==> | 6rd-relays| |<-----| 0.0.0.0/0 |----->| : ||______________V_______________|__|__ISP-supported NAT(s) | ||_____||VIPv4 public addressesFigure 3: 6rd Applicability to ISPs That AssignIPv4 Private AddressesFree currently offers a global IPv4 address to each of itssubscribers, which ensures that all IPv4-derived prefixes using 6rdare unique. Service providers may no longer have this luxury asavailable global IPv4 addresses become more and more scarce. Thissection describes how 6rd could be used by a service provider whocannot provide global IPv4 addresses to each subscriber.If an ISP has assigned to customer sites addresses of an IPv4 private space of [RFC1918], typically 10.x.x.x addresses, it can also use 6rd to offer IPv6 to these sites.IPv4 packets that contain IPv6 packets don’t go to NATs that this ISP needs to operate in its infrastructure: they go directly to 6rdrelays because their destination is the 6rd relay anycast address.It can be noted that in this case, the 10.0.0.0/8 prefix is common to all IPv4 addresses of the addressing domain in which 6rd is used.Knowing it, gateways and CPEs could avoid including this constantIPv4 prefix in IPv6 prefixes, and thus reduce to 24 the number ofbits of IPv4 addresses that are included in IPv6 prefixes (but thiswas not applicable to Free).Despres Informational [Page 7]It can also be noted that, if an ISP is large enough to provideservice to more IPv4 endpoints than will fit inside a single10.0.0.0/8 addressing domain, it can configure several such domains, with 6rd-relay IPv6 prefixes specific of each one. Each of theseprefixes is then the RIR-allocated ISP prefix followed by a domainidentifier chosen by the ISP.5. Security ConsiderationsSecurity considerations for 6to4 are documented in [RFC3964]. Withthe restriction imposed by 6rd that relays of an ISP deal only withtraffic that belongs to that ISP, checks that have to be done become the following:o CPE PACKETS TOWARD THE INTERNET: The IPv6 source must be, and the IPv6 destination must not be, a 6rd address of the site.o RELAY PACKETS TOWARD THE INTERNET: The IPv6 source must be a 6rdaddress that matches the IPv4 source. The IPv6 destination mustnot start with the ISP 6rd prefix.o CPE PACKETS FROM THE INTERNET: If the IPv4 source is the 6rd-relay’s anycast address of the local ISP, the IPv6 source must not be a 6rd address of this ISP. Otherwise, the IPv6 source must be the 6rd address that matches the IPv4 source (is the IPv6 prefixof 6rd relays of the ISP followed by the IPv4 address).o RELAY PACKETS FROM THE INTERNET: The IPv6 source must not be a 6rd address of the ISP. The IPv4 destination must not be multicast,i.e., must not start with 224/3. The fact that the IPv6destination starts with the IPv6 prefix of the ISP 6rd relays isensured by the routing configuration, but may be double-checked.It remains that where IPv4 address spoofing is possible (IPv4 sitesplacing unauthorized source addresses in some packets they send),IPv6 address spoofing is also possible, independently of the aboveprecautions.6. IANA ConsiderationsISPs that provide CPEs to all their customers need no new numberassignment by IANA. Their being allocated an IPv6 prefix by theirRIR, /32 or shorter, is sufficient.Despres Informational [Page 8]For 6rd to be also used in the future by ISPs that let customers have their own CPEs, means to communicate 6rd parameters to these CPEswould be needed. If the IETF specifies such means for this, somenumber assignment by IANA is likely to be solicited, in a registry to be then defined.7. AcknowledgementsThe author warmly acknowledges the major contribution of Rani Assafto 6rd’s proven credibility. He readily appreciated 6rd’s potential, and made the daring decision to immediately implement it for a veryrapid deployment on Free’s operational network.Mark Townsley, Brian Carpenter and Patrick Grossetete have to bethanked for their encouragements, and for their suggestions on how to proceed for 6rd to be known in the IETF.Acknowledgments are also due to some IPv6 old timers, in particularLaurent Toutain, Francis Dupont, and Alain Durand, who, when theauthor came as a late novice on IPV6, taught him a few subtleties of the subject. Without them, designing 6rd would probably not havebeen possible.8. References8.1. Normative References[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domainsvia IPv4 Clouds", RFC 3056, February 2001.[RFC4291] Hinden, R. and S. Deering, "IP Version 6 AddressingArchitecture", RFC 4291, February 2006.8.2. Informative References[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets",BCP 5, RFC 1918, February 1996.[RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers",RFC 3068, June 2001.[RFC3964] Savola, P. and C. Patel, "Security Considerations for6to4", RFC 3964, December 2004.Despres Informational [Page 9]Author’s AddressRemi DespresRD-IPtech3 rue du President WilsonLevallois,FrancePhone: +33 6 72 74 94 88EMail: remi.despres@free.frDespres Informational [Page 10]。
手动配置 IPv6
作者：Cable Guy
欲了解关于Cable Guy所主持的所有专栏的列表和更多信息，请单击此处。
在大多数情况下，运行 Windows XP 或 Windows Server 2003 家族成员之一的 IPv6 主机不必采用手动配置。然而在某些情况下，您必须对计算机手动配置 IPv6 地址。此外，有时某台计算机在网络上还具有特殊的作用。
netsh interface ipv6 set interface "Local Area Connection"
forwarding=enabled advertise=enabled
netsh interface ipv6 set interface "Local Area Connection 2"
netsh interface ipv6 set interface "6to4 Pseudo-Interface"
forwarding=enabled
? 向连接到 intranet 的接口添加 6to4 前缀的路由，并配置其进行公布。这可以通过以下命令来完成：
netsh interface ipv6 add route 2002:WWXX:YYZZ: SubnetID::/64
默认情况下，地址类型是单播的（unicast），有效和首选的生存期是无限的（infinite），并且地址是持久的（persistent）。为了获得接口名称或其索引，您可以使用netsh interface IPv6 show interface命令的显示。
例如，要在名为 Local Area Connection 的接口上配置站点局部地址 FEC0::1A49:2AA:FF:FE34:CA8F，相应的命令为：
ipv6测试解决方案
所以确保双栈路由器可以可以完成以下功能是至关重要的:
©2006 Ixia. All rights reserved.
IPv6 一致性测试
根据IPv6标准的每行描述准确的制定自动化测试案例库 – IPv6 一致 性测试套件 彻底检查每个RFC定义的功能 实施一致性测试保证设备的互连互通 在产品设计阶段就发现问题，而不是到客户现场解决问题!! 为回归测试提供基准 帮助运营商和ISP诊断互操作问题 测试工具- IxANVL
©2006 Ixia. All rights reserved.
IPv6测试平台及典型配置
IXIA公司是全球领先的最大的IP测试公司之一
– – 连续29个季度赢利 销售额在1998至2005年间增长超过2200%，年销售额超过1.5亿美元
一致性工具：IxANVL IPv6双栈路由器功能及性能工具：IxNetwork、IxScripteMate IPv6 BRAS功能及性能工具：IxAccess、IxNetwork IPv6 VPN网关功能及性能工具：IxVPN IPv6 应用层功能及性能工具：IxLoad、IxChariot
面向IPv6 测试解决方案
Jason Han Senior System Engineer, Ixia jhan@
议程
IPv6 测试的重要性，必要性 IPv4 到 IPv6 演变策略 主要测试方向 IPv6 一致性测试 IPv4/IPv6 功能和性能测试 IPv6/IPv4 隧道测试 路由性能和扩展性测试 组播性能和扩展性测试
输入
指定负载 报文长 地址范围
结果
吞吐量, 时延, 丢包 率
©2006 Ixia. All rights reserved.
路由性能和扩展性
网件路由防火墙及路由器IPv6功能
网件路由防火墙及路由器IPv6功能网件公司的产品销售全球，也是美国高科技企业连续八年增长速度最快的50家之一，那么你知道网件路由防火墙及路由器IPv6功能吗?下面是店铺整理的一些关于网件路由防火墙及路由器IPv6功能的相关资料，供你参考。
网件路由防火墙及路由器IPv6功能首先是隧道 6to4 TunnelingIPv6to4适用于将IPv6孤岛通过纯IPv4网络接入其他IPv6区域，这是一种点到多点连接.6to4的定义由RFC3056提供。
对于防火墙设备，进入Network Configuration > WAN Settings > WAN Mode 选中IPv4 / IPv6 mode 以开启双栈(Dual-stack)模式在开启 6to4 前要保证设备WAN口为静态IP地址.进入Network Configuration > WAN Settings > Broadband ISP Settings 设置。
开启6to4 隧道，进入Network Configuration > WAN Settings > 6to4 Tunneling勾选 Enable Automatic Tunneling点击APPLY以应用如果内网没有部署状态化DHCPv6服务器，需要启用防火墙的RADVD守护进程(Router Advertisement Daemon)，设置过程参考附录7，本例中，Type选为6to4，此时Prefix将以IANA对6to4的分配方式生成， SLA ID与Lifetime可以手工输入。
防火墙LAN侧收到上述Prefix宣告后会根据EUI-64规则生成Interface ID.最后要做的是写一个发往6to4对端ipv6地址的静态路由进入 Network Configuration > Routing单选IPv6点击Add添加Destination可以写成2002::/16或按需填写Interface 要选择sit TunnelGateway填写Tunnel对端IPv6地址点击APPLY以应用对于家用路由器进入 ADVANCED > Advanced Setup > IPv6选择 6to4 TunnelRemote 6to4 Relay Router，如果您的ISP支持其自己的中继路由器地址，您可以在Static IP Address 输入地址.也可以保留"Auto"，路由器将使用任何可用的地址.LAN Setup可以选择IP Address Assignment方式(DHCPv6或Auto Config)，此处设置的是您希望的内网设备获取IP地址的方式.LAN Setup的另一个选项是Use This Interface ID，可以在勾选复选框后将自定义接口ID输入文本框内.路由器将自动创建隧道并生成路由条目，毋需手工设置需要说明的是IETF定义的6to4是一种点对多点隧道，应允许使用更少的配置步骤自动连接多个IPv6孤岛，既然6to4不像手工隧道(手工隧道技术不在NETGEAR设备支持范围内)一样需要配置对端IP地址，那么6to4隧道的IPv6地址一定与其出口IPv4地址存在某种关联;根据IANA的分配，2002::/16被保留给6to4隧道，并按照2002:IPv4address:EUI-64(或2002:IPv4address:ManuallyInterfaceID)的规则生成IPv6地址(定义于RFC2056)。
因特网6to4机制的分析与实现
第29卷第2期 2006年4月 电 子 测 量 技 术 EL ECTRON IC M EASUREM EN T TECHNOLO GY信息技术因特网6to4机制的分析与实现杨 闽 于 健 戴居丰(天津大学电子信息工程学院天津300072)摘 要:6to4机制用于解决孤立的IPv6站点之间的通信问题。
文中通过配置6to4边界路由器和6to4主机实现了IPv6主机与6bone网络的连接。
结果表明在IPv4和IPv6的共存阶段6to4机制具有一定的应用价值。
关键词:6to4 隧道技术 6bone.Analysis and implementation of Internet6to4mechanismYang Min Yu Jian Dai J ufeng(School of Electronics Information Engineering,Tianjin University,Tianjin,300072)Abstract:6to4mechanism allows isolated IPv6sites to communication with each other.With configuring the6to4 router and host,the connection of IPv6sites with6bone is realized.The results show that the application of6to4 mechanism has practical value during the period of co2existence of IPv4and IPv6.K eyw ords:6to4,tunneling technique,6bone.0 6to4机制6to4[1]是一种地址分配和路由器到路由器的自动隧道技术,它为IPv6站点和主机之间提供了跨IPv4Internet的单播IPv6连通性,解决了在没有Internet服务提供商提供IPv6互连服务的条件下,孤立的IPv6站点与其他孤立站点以及与IPv6主干网内部各站点之间的通信问题。
4to6过度
内容
过渡过程 IPv4/IPv6过渡机制
IPv4/IPv6双协议栈(Dual-stack) 隧道技术(Tunnelling) 转换机制(Translation Mechanism)
移动IPv4/移动IPv6过渡机制
内容
过渡过程 IPv4/IPv6过渡机制
IPv4/IPv6双协议栈(Dual-stack) 隧道技术(Tunnelling) 转换机制(Translation Mechanism)
移动IPv4/移动IPv6过渡机制
过渡过程
当前状态 IPv4 IPv4 Only IPv6 IPv6 IPv6 IPv4 IPv6 IPv4 IPv4 IPv6 Only
内容
过渡过程 IPv4/IPv6过渡机制
IPv4/IPv6双协议栈(Dual-stack) 隧道技术(Tunnelling) 转换机制(Translation Mechanism)
ISATAP(Intra-site Automatic Tunnel Addressing Protocol )地址 地址
比特单播地址前缀和::0:5EFE:w.x.y.z，其中 其中w.x.y.z是分配给接口 由64比特单播地址前缀和 比特单播地址前缀和 是分配给接口 的单播IPv4地址 的单播 地址
移动IPv4/移动IPv6过渡机制
移动IPv4/移动IPv6双栈
对移动IPv6进行移动IPv4扩展,使得移动 IPv4/移动IPv6节点能够使用移动IPv6信令 来完成移动IPv4和移动IPv6绑定注册过程 对移动IPv4进行移动IPv6扩展,使得移动 IPv4/移动IPv6节点能够使用移动IPv4信令 来完成移动IPv4和移动IPv6绑定注册过程 对移动IPv4和移动IPv6进行扩展，使得移 动节点能注册一个IPv4或者IPv6转交地址， 用于IPv4或者IPv6分组的隧道转发
RFC5214(中文)-站点内部自动隧道寻址协议(ISATAP)
潜在路由器列表(Potential Router List, PRL) 一组关于潜在路由器的条目；用于支持路由器发现和前缀发现。每个条目“( PRL(i)”) 有关联的计时器(“TIMER(i)”)，和 IPv4 地址(“V4ADDR(i)”)，该地址代表路由 器的通告 ISATAP 接口。
须假设它下面的 IPv4 承载网络只有单播能力。 本文件没有描述在 ISATAP 接口上支持 IPv6 多播。类似，本文件没有描述对 Reserved
IPv6 Subnet Anycast Addresses 的支持。
第 7 章 自动隧道化 ISATAP 接口使用基本的隧道化机制，该机制在[RFC4213]第 3 章描述。下述各小节描
第 2 章 要求 本文件中，关键词“MUST”、“MUST NOT”、“REQUIRED”、“SHALL”、“SHALL NOT”、
“SHOULD”、“SHOULD NOT”、“RECOMMENDED”、“MAY”和“OPTIONAL”的含义 遵从[RFC-2119]规定。
本文件也使用内部概念性变量描述协议行为，使用实现中必须允许系统管理者改变的外 部变量。本文件提供特定变量名称，变量值如何改变，以及变量设置如何影响协议行为等内 容，以便演示协议行为。不要求实现中和这里完全一样地使用它们，只要其外在行为与本文 件描述的一致即可。
无论使用的是全球IPv4地址还是私有IPv4地址，ISATAP都能对其自动隧道化，并且 ISATAP呈现了类似于[RFC2491]、[RFC2492]、[RFC2529]和[RFC3056]的非广播多路访问 (Non-Broadcast Multiple Access, NBMA)机制。
RFC3056(中文) 经IPv4云连接IPv6域
本文翻译者：weicq2000RFC3056 经IPv4云连接IPv6域(2001年2月)摘录本备忘录为在IPv4网络上没有建立显示隧道的拟相互通信IPv6站点，规定了一种可选的过渡性机制，使它们能够通过中继路由器与本地IPv6域通信。
实际上，它将广域IPv4网络当作单播点对点链路层。
此机制仅希望用作IPv4和IPv6共存期间的一个转换工具，不打算成为永久解决方案。
本文件定义了分配过渡性唯一IPv6地址前缀到目前至少有一个全球唯一IPv4地址的任意站点的方法，规定了使用这样的前缀在全球IPv4网络上传送IPv6分组的封装机制。
提出此方法的想法是允许附着到IPv4网络(该网络没有本地IPv6支持)上的、隔离的IPv6域或主机，在它们连通本地IPv6之前，采用最少人工配置，实现与其他这样的IPv6域或主机相互通信。
此方法偶然也提供过渡性全球唯一IPv6地址前缀给至少有一个全球唯一IPv4地址的任何站点，虽然是与IPv4网络地址转换器(Network Address Translator, NAT)组合使用。
目录第1章引言1-1 术语第2章IPv6前缀分配2-1 地址选择第3章用IPv4封装3-1 链路本地地址和NUD第4章最大传输单元第5章单播场景、度量和转换到常规前缀5-1 简单场景---所有站点工作相同5-2 带有到本地IPv6中继的混合场景5-2-1 带有ISP中继的变化场景5-2-2 归纳中继路由器配置5-2-2-1 不使用BGP4+5-2-2-2 使用BGP4+5-2-2-3 中继路由器度量5-2-3 非情愿中继5-3 发送规则和解封装规则5-4 具有到IPv6空间的隧道的各种场景5-5 分隔场景5-6 多归属地5-7 转换考虑5-8 与防火墙、NAT或RSIP共存5-9 在内联网中的应用5-10 归纳对路由的影响5-11 路由环路预防第6章多播和任播第7章ICMP消息第8章IANA考虑s第9章安全考虑致谢参考文献撰写者通讯录知识产权完全版权声明第1章序言本备忘录描述了一种可选的过渡性机制，该机制可使在IPv4网络上没有建立显示隧道的IPv6站点间相互通信，可使这些站点经中继路由器与本地IPv6域通信。
6to4自动隧道
6to4自动隧道（作者：猎豹网校—吴志峰）6to4隧道也被称为6-to-4隧道，用于通过IPv4网络将IPv6域连接起来，它是点到多点连接类型。
边缘路由器使用其隧道接口的IPv6地址内嵌IPv4地址自动创建6to4通道。
每台6to4边缘路由器都是双栈设备，有一个前缀为/48的IPv6地址，是由2002::/16和边缘路由器的IPv4地址组合而成。
在RFC3056中定义的2002::/16的地址范围专用于6to4隧道的地址范围。
边缘路由器自动使用嵌入在IPv6中的IPv4地址建立隧道。
例如：如果边缘路由器的IPv4地址为192.168.99.1，则其IPv6地址为2002:c0a8:6301::/48,因为192.168.99.1的十六进制表示为c0a8:6301。
下图说明了转换过程：十进制192 168 99 1二进制11000000 10101000 11100011 00000001十六进制C0 A8 63 01通过使用6to4隧道，可在公司网络中快速部署IPv6的网络，而无需向ISP或注册机构申请公有IPv6地址。
例：在上图这个例子中：边缘6to4路由器A收到目标地址2002:c0a8:1e01::/48的数据包（注：2002:c0a8:1e01::/48地址位于2002::/16的IPv6分组内），路由器A根据它自己的路由表知道必须使用隧道来传输数据，所以路由器A从目标的IPv6地址中提取c0a8:1e01做为到达目标路由器的IPv4地址，也就是隧道的另一端6to4路由器B的IPv4地址。
路由器A将IPv6的分组封装到IPv4分组中，并将提取的IPv4地址（路由器B的IPv4地址）用作目标地址，随后分组穿过IPv4的网络。
路由器B收到IPv4的分组后，将其拆封以获得其中的IPv6分组，并将其转发到最终的目的地。
配置和验证6to4隧道。
地址表：一、R1路由器基本配置R1>enable #进入特权模式R1#configure terminal #进入全局配置模式R1(config)#ipv6 unicast-routing #开启IPv6的单播路由R1(config)#interface serial 1/0 #进入R1路由器串口1/0R1(config-if)#ip address 172.16.12.1 255.255.255.0 #增加IPv4的地址R1(config-if)#no shutdown #打开串行端口R1(config-if)#interface FastEthernet0/0 #切换到快速以太口0/0R1(config-if)#ipv6 address 13::1/64 #给快速以太口增加IPv6地址R1(config-if)#no shutdown #打开快速以太口R1(config-if)#exit #退出端口配置模式R1(config)#interface loopback 101 #设置一个虚拟环路端口编号为101R1(config-if)#ip address 17.16.101.1 255.255.255.0 #给虚拟环路端口增加IPv4地址R1(config-if)#exit #退出虚拟环路端口设置R1(config)#二、R2 路由器基本配置R2>enable #进入特权模式R2#configure terminal #进入全局配置模式R2(config)#ipv6 Unicast-routing #开启IPv6的单播路由R2(config)#interface serial 1/0 #进入R2路由器串口1/0R2(config-if)#ip address 172.16.12.2 255.255.255.0 #增加IPv4的地址R2(config-if)#no shutdown #打开串行端口R2(config-if)#interface FastEthernet0/0 #切换到快速以太口0/0R2(config-if)#ipv6 address 24::2/64 #给快速以太口增加IPv6地址R2(config-if)#no shutdown #打开快速以太口R2(config-if)#exit #退出端口配置模式R2(config)#interface loopback 102 #设置一个虚拟环路端口编号为102R2(config-if)#ip address 172.16.102.1 255.255.255.0 #给虚拟环路端口增加IPv4地址R2(config-if)#exit #退出虚拟环路端口设置R2(config)#三、R3 路由器基本配置R3>enable #进行特权模式R3#configure terminal #进入全局配置模式R3(config)#ipv6 unicast-routing #开启IPv6的单播路由R3(config)#interface fastethernet0/0 #进入快速以太口R3(config-if)#ipv6 address 13::3/64 #给快速以太口配置IPv6地址R3(config-if)#exit #退出端口配置模式四、R4路由器基本配置R4>enable #进行特权模式R4#configure terminal #进入全局配置模式R4(config)#ipv6 unicast-routing #开启IPv6的单播路由R4(config)#interface fastethernet0/0 #进入快速以太口R4(config-if)#ipv6 address 24::4/64 #给快速以太口配置IPv6地址R4(config-if)#exit #退出端口配置模式五、R1路由器启用RIPv2协议R1(config)#router rip #启动rip设置协议R1(config-router)#version 2 #设置Rip协议版本R1(config-router)#network 172.16.12.1 #宣告R1路由器上现有的IPv4网络R1(config-router)#network 172.16.101.1 #宣告R1路由器上现有的IPv4网络R1(config-router)#exit #退出Rip设置协议R1(config)#end #退到特权模式R1#六、R2路由器启用RIPv2协议R2(config)#router rip #启动rip设置协议R2(config-router)#version 2 #设置Rip协议版本R2(config-router)#network 172.16.12.2 #宣告R2路由器上现有的IPv4网络R2(config-router)#network 172.16.102.1 #宣告R2路由器上现有的IPv4网络R2(config-router)#exit #退出Rip设置协议R2(config)#end #退到特权模式R2#七、查看R1路由表R1#show ip route如下图：八、查看R2路由表R1#show ip route如下图九、配置手工隧道在路由器R1和R2之间创建一条手工隧道，并将R1和R2的环回接口用作隧道源接口。
6to4自动隧道
6to4自动隧道（作者：猎豹网校—吴志峰）6to4隧道也被称为6-to-4隧道，用于通过IPv4网络将IPv6域连接起来，它是点到多点连接类型。
边缘路由器使用其隧道接口的IPv6地址内嵌IPv4地址自动创建6to4通道。
每台6to4边缘路由器都是双栈设备，有一个前缀为/48的IPv6地址，是由2002::/16和边缘路由器的IPv4地址组合而成。
在RFC3056中定义的2002::/16的地址范围专用于6to4隧道的地址范围。
边缘路由器自动使用嵌入在IPv6中的IPv4地址建立隧道。
例如：如果边缘路由器的IPv4地址为192.168.99.1，则其IPv6地址为2002:c0a8:6301::/48,因为192.168.99.1的十六进制表示为c0a8:6301。
下图说明了转换过程：十进制192 168 99 1二进制11000000 10101000 11100011 00000001十六进制C0 A8 63 01通过使用6to4隧道，可在公司网络中快速部署IPv6的网络，而无需向ISP或注册机构申请公有IPv6地址。
例：在上图这个例子中：边缘6to4路由器A收到目标地址2002:c0a8:1e01::/48的数据包（注：2002:c0a8:1e01::/48地址位于2002::/16的IPv6分组内），路由器A根据它自己的路由表知道必须使用隧道来传输数据，所以路由器A从目标的IPv6地址中提取c0a8:1e01做为到达目标路由器的IPv4地址，也就是隧道的另一端6to4路由器B的IPv4地址。
路由器A将IPv6的分组封装到IPv4分组中，并将提取的IPv4地址（路由器B的IPv4地址）用作目标地址，随后分组穿过IPv4的网络。
路由器B收到IPv4的分组后，将其拆封以获得其中的IPv6分组，并将其转发到最终的目的地。
配置和验证6to4隧道。
地址表：一、R1路由器基本配置R1>enable #进入特权模式R1#configure terminal #进入全局配置模式R1(config)#ipv6 unicast-routing #开启IPv6的单播路由R1(config)#interface serial 1/0 #进入R1路由器串口1/0R1(config-if)#ip address 172.16.12.1 255.255.255.0 #增加IPv4的地址R1(config-if)#no shutdown #打开串行端口R1(config-if)#interface FastEthernet0/0 #切换到快速以太口0/0R1(config-if)#ipv6 address 13::1/64 #给快速以太口增加IPv6地址R1(config-if)#no shutdown #打开快速以太口R1(config-if)#exit #退出端口配置模式R1(config)#interface loopback 101 #设置一个虚拟环路端口编号为101R1(config-if)#ip address 17.16.101.1 255.255.255.0 #给虚拟环路端口增加IPv4地址R1(config-if)#exit #退出虚拟环路端口设置R1(config)#二、R2 路由器基本配置R2>enable #进入特权模式R2#configure terminal #进入全局配置模式R2(config)#ipv6 Unicast-routing #开启IPv6的单播路由R2(config)#interface serial 1/0 #进入R2路由器串口1/0R2(config-if)#ip address 172.16.12.2 255.255.255.0 #增加IPv4的地址R2(config-if)#no shutdown #打开串行端口R2(config-if)#interface FastEthernet0/0 #切换到快速以太口0/0R2(config-if)#ipv6 address 24::2/64 #给快速以太口增加IPv6地址R2(config-if)#no shutdown #打开快速以太口R2(config-if)#exit #退出端口配置模式R2(config)#interface loopback 102 #设置一个虚拟环路端口编号为102R2(config-if)#ip address 172.16.102.1 255.255.255.0 #给虚拟环路端口增加IPv4地址R2(config-if)#exit #退出虚拟环路端口设置R2(config)#三、R3 路由器基本配置R3>enable #进行特权模式R3#configure terminal #进入全局配置模式R3(config)#ipv6 unicast-routing #开启IPv6的单播路由R3(config)#interface fastethernet0/0 #进入快速以太口R3(config-if)#ipv6 address 13::3/64 #给快速以太口配置IPv6地址R3(config-if)#exit #退出端口配置模式四、R4路由器基本配置R4>enable #进行特权模式R4#configure terminal #进入全局配置模式R4(config)#ipv6 unicast-routing #开启IPv6的单播路由R4(config)#interface fastethernet0/0 #进入快速以太口R4(config-if)#ipv6 address 24::4/64 #给快速以太口配置IPv6地址R4(config-if)#exit #退出端口配置模式五、R1路由器启用RIPv2协议R1(config)#router rip #启动rip设置协议R1(config-router)#version 2 #设置Rip协议版本R1(config-router)#network 172.16.12.1 #宣告R1路由器上现有的IPv4网络R1(config-router)#network 172.16.101.1 #宣告R1路由器上现有的IPv4网络R1(config-router)#exit #退出Rip设置协议R1(config)#end #退到特权模式R1#六、R2路由器启用RIPv2协议R2(config)#router rip #启动rip设置协议R2(config-router)#version 2 #设置Rip协议版本R2(config-router)#network 172.16.12.2 #宣告R2路由器上现有的IPv4网络R2(config-router)#network 172.16.102.1 #宣告R2路由器上现有的IPv4网络R2(config-router)#exit #退出Rip设置协议R2(config)#end #退到特权模式R2#七、查看R1路由表R1#show ip route如下图：八、查看R2路由表R1#show ip route如下图九、配置手工隧道在路由器R1和R2之间创建一条手工隧道，并将R1和R2的环回接口用作隧道源接口。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
Network Working Group B. Carpenter Request for Comments: 3056 K. Moore Category: Standards Track February 2001 Connection of IPv6 Domains via IPv4 CloudsStatus 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. Copyright NoticeCopyright (C) The Internet Society (2001). All Rights Reserved. AbstractThis memo specifies an optional interim mechanism for IPv6 sites tocommunicate with each other over the IPv4 network without explicittunnel setup, and for them to communicate with native IPv6 domainsvia relay routers. Effectively it treats the wide area IPv4 network as a unicast point-to-point link layer. The mechanism is intended as a start-up transition tool used during the period of co-existence of IPv4 and IPv6. It is not intended as a permanent solution.The document defines a method for assigning an interim unique IPv6address prefix to any site that currently has at least one globallyunique IPv4 address, and specifies an encapsulation mechanism fortransmitting IPv6 packets using such a prefix over the global IPv4network.The motivation for this method is to allow isolated IPv6 domains orhosts, attached to an IPv4 network which has no native IPv6 support, to communicate with other such IPv6 domains or hosts with minimalmanual configuration, before they can obtain natuve IPv6connectivity. It incidentally provides an interim globally uniqueIPv6 address prefix to any site with at least one globally uniqueIPv4 address, even if combined with an IPv4 Network AddressTranslator (NAT).Carpenter & Moore Standards Track [Page 1]Table of Contents1. Introduction (2)1.1. Terminology (4)2. IPv6 Prefix Allocation (5)2.1 Address Selection (6)3. Encapsulation in IPv4 (6)3.1. Link-Local Address and NUD (7)4. Maximum Transmission Unit (7)5. Unicast scenarios, scaling, and transition to normal prefixes 85.1 Simple scenario - all sites work the same (8)5.2 Mixed scenario with relay to native IPv6 (9)5.2.1 Variant scenario with ISP relay (12)5.2.2 Summary of relay router configuration (12)5.2.2.1. BGP4+ not used (12)5.2.2.2. BGP4+ used (12)5.2.2.3. Relay router scaling (13)5.2.3 Unwilling to relay (13)5.3 Sending and decapsulation rules (13)5.4 Variant scenario with tunnel to IPv6 space (14)5.5 Fragmented Scenarios (14)5.6 Multihoming (16)5.7 Transition Considerations (16)5.8 Coexistence with firewall, NAT or RSIP (16)5.9 Usage within Intranets (17)5.10 Summary of impact on routing (18)5.11. Routing loop prevention (18)6. Multicast and Anycast (19)7. ICMP messages (19)8. IANA Considerations (19)9. Security Considerations (19)Acknowledgements (20)References (20)Authors’ Addresses (22)Intellectual Property (22)Full Copyright Statement (23)1. IntroductionThis memo specifies an optional interim mechanism for IPv6 sites tocommunicate with each other over the IPv4 network without explicittunnel setup, and for them to communicate with native IPv6 domainsvia relay routers. Effectively it treats the wide area IPv4 network as a unicast point-to-point link layer. The mechanism is intended as a start-up transition tool used during the period of co-existence of IPv4 and IPv6. It is not intended as a permanent solution.Carpenter & Moore Standards Track [Page 2]The document defines a method for assigning an interim unique IPv6address prefix to any site that currently has at least one globallyunique IPv4 address, and specifies an encapsulation mechanism fortransmitting IPv6 packets using such a prefix over the global IPv4network. It also describes scenarios for using such prefixes during the co-existence phase of IPv4 to IPv6 transition. Note that thesescenarios are only part of the total picture of transition to IPv6.Also note that this is considered to be an interim solution and that sites should migrate when possible to native IPv6 prefixes and native IPv6 connectivity. This will be possible as soon as the site’s ISPoffers native IPv6 connectivity.The basic mechanism described in the present document, which applies to sites rather than individual hosts, will scale indefinitely bylimiting the number of sites served by a given relay router (seeSection 5.2). It will introduce no new entries in the IPv4 routingtable, and exactly one new entry in the native IPv6 routing table(see Section 5.10).Although the mechanism is specified for an IPv6 site, it can equally be applied to an individual IPv6 host or very small site, as long as it has at least one globally unique IPv4 address. However, thelatter case raises serious scaling issues which are the subject offurther study [SCALE].The motivation for this method is to allow isolated IPv6 sites orhosts, attached to a wide area network which has no native IPv6support, to communicate with other such IPv6 domains or hosts withminimal manual configuration.IPv6 sites or hosts connected using this method do not require IPv4- compatible IPv6 addresses [MECH] or configured tunnels. In this way IPv6 gains considerable independence of the underlying wide areanetwork and can step over many hops of IPv4 subnets. The abbreviated name of this mechanism is 6to4 (not to be confused with [6OVER4]).The 6to4 mechanism is typically implemented almost entirely in border routers, without specific host modifications except a suggestedaddress selection default. Only a modest amount of routerconfiguration is required.Sections 2 to 4 of this document specify the 6to4 scheme technically. Section 5 discusses some, but not all, usage scenarios, includingrouting aspects, for 6to4 sites. Scenarios for isolated 6to4 hostsare not discussed in this document. Sections 6 to 9 discuss othergeneral considerations.Carpenter & Moore Standards Track [Page 3]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 [RFC2119].1.1. TerminologyThe terminology of [IPV6] applies to this document.6to4 pseudo-interface:6to4 encapsulation of IPv6 packets inside IPv4 packets occursat a point that is logically equivalent to an IPv6 interface,with the link layer being the IPv4 unicast network. This point is referred to as a pseudo-interface. Some implementors maytreat it exactly like any other interface and others may treat it like a tunnel end-point.6to4 prefix:an IPv6 prefix constructed according to the rule in Section 2below.6to4 address: an IPv6 address constructed using a 6to4 prefix.Native IPv6 address: an IPv6 address constructed using another type of prefix than 6to4.6to4 router (or 6to4 border router):an IPv6 router supporting a 6to4 pseudo-interface. It isnormally the border router between an IPv6 site and a wide-area IPv4 network.6to4 host:an IPv6 host which happens to have at least one 6to4 address.In all other respects it is a standard IPv6 host.Note: an IPv6 node may in some cases use a 6to4 address for aconfigured tunnel. Such a node may function as an IPv6 host using a 6to4 address on its configured tunnel interface, and it may alsoserve as a IPv6 router for other hosts via a 6to4 pseudo-interface,but these are distinct functions.6to4 site:a site running IPv6 internally using 6to4 addresses, therefore containing at least one 6to4 host and at least one 6to4 router. Carpenter & Moore Standards Track [Page 4]Relay router:a 6to4 router configured to support transit routing between6to4 addresses and native IPv6 addresses.6to4 exterior routing domain:a routing domain interconnecting a set of 6to4 routers andrelay routers. It is distinct from an IPv6 site’s interiorrouting domain, and distinct from all native IPv6 exteriorrouting domains.2. IPv6 Prefix AllocationSuppose that a subscriber site has at least one valid, globallyunique 32-bit IPv4 address, referred to in this document as V4ADDR.This address MUST be duly allocated to the site by an addressregistry (possibly via a service provider) and it MUST NOT be aprivate address [RFC 1918].The IANA has permanently assigned one 13-bit IPv6 Top LevelAggregator (TLA) identifier under the IPv6 Format Prefix 001 [AARCH, AGGR] for the 6to4 scheme.Its numeric value is 0x0002, i.e., it is2002::/16 when expressed as an IPv6 address prefix.The subscriber site is then deemed to have the following IPv6 address prefix, without any further assignment procedures being necessary:Prefix length: 48 bitsFormat prefix: 001TLA value: 0x0002NLA value: V4ADDRThis is illustrated as follows:| 3 | 13 | 32 | 16 | 64 bits | +---+------+-----------+--------+--------------------------------+ |FP | TLA | V4ADDR | SLA ID | Interface ID | |001|0x0002| | | | +---+------+-----------+--------+--------------------------------+ Thus, this prefix has exactly the same format as normal /48 prefixes assigned according to [AGGR]. It can be abbreviated as2002:V4ADDR::/48. Within the subscriber site it can be used exactly like any other valid IPv6 prefix, e.g., for automated addressassignment and discovery according to the normal mechanisms such as[CONF, DISC], for native IPv6 routing, or for the "6over4" mechanism [6OVER4].Carpenter & Moore Standards Track [Page 5]Note that if the IPv4 address is assigned dynamically, thecorresponding IPv6 prefix will also be dynamic in nature, with thesame lifetime.2.1 Address SelectionTo ensure the correct operation of 6to4 in complex topologies, source and destination address selection must be appropriately implemented. If the source IPv6 host sending a packet has at least one 2002::address assigned to it, and if the set of IPv6 addresses returned by the DNS for the destination host contains at least one 2002::address, then the source host must make an appropriate choice of the source and destination addresses to be used. The mechanisms foraddress selection in general are under study at the time of writing[SELECT]. Subject to those general mechanisms, the principle thatwill normally allow correct operation of 6to4 is this:If one host has only a 6to4 address, and the other one has both a6to4 and a native IPv6 address, then the 6to4 address should be used for both.If both hosts have a 6to4 address and a native IPv6 address, theneither the 6to4 address should be used for both, or the native IPv6address should be used for both. The choice should be configurable. The default configuration should be native IPv6 for both.3. Encapsulation in IPv4IPv6 packets from a 6to4 site are encapsulated in IPv4 packets whenthey leave the site via its external IPv4 connection. Note that the IPv4 interface that is carrying the 6to4 traffic is notionallyequivalent to an IPv6 interface, and is referred to below as apseudo-interface, although this phrase is not intended to define animplementation technique. V4ADDR MUST be configured on the IPv4interface.IPv6 packets are transmitted in IPv4 packets [RFC 791] with an IPv4protocol type of 41, the same as has been assigned [MECH] for IPv6packets that are tunneled inside of IPv4 frames. The IPv4 headercontains the Destination and Source IPv4 addresses. One or both ofthese will be identical to the V4ADDR field of an IPv6 prefix formed as specified above (see section 5 for more details). The IPv4 packet body contains the IPv6 header and payload.Carpenter & Moore Standards Track [Page 6]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+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|Version| IHL |Type of Service| Total Length |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Identification |Flags| Fragment Offset |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Time to Live | Protocol 41 | Header Checksum |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Source Address |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Destination Address |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Options | Padding |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| IPv6 header and payload ... /+-------+-------+-------+-------+-------+------+------+The IPv4 Time to Live will be set as normal [RFC 791], as will theencapsulated IPv6 hop limit [IPv6]. Other considerations are asdescribed in Section 4.1.2 of [MECH].3.1. Link-Local Address and NUDThe link-local address of a 6to4 pseudo-interface performing 6to4encapsulation would, if needed, be formed as described in Section 3.7 of [MECH]. However, no scenario is known in which such an addresswould be useful, since a peer 6to4 gateway cannot determine theappropriate link-layer (IPv4) address to send to.Neighbor Unreachability Detection (NUD) is handled as described inSection 3.8 of [MECH].4. Maximum Transmission UnitMTU size considerations are as described for tunnels in [MECH].If the IPv6 MTU size proves to be too large for some intermediateIPv4 subnet, IPv4 fragmentation will ensue. While undesirable, this is not necessarily disastrous, unless the fragments are delivered to different IPv4 destinations due to some form of IPv4 anycast. TheIPv4 "do not fragment" bit SHOULD NOT be set in the encapsulatingIPv4 header.Carpenter & Moore Standards Track [Page 7]5. Unicast scenarios, scaling, and transition to normal prefixes5.1 Simple scenario - all sites work the sameThe simplest deployment scenario for 6to4 is to use it between anumber of sites, each of which has at least one connection to ashared IPv4 Internet. This could be the global Internet, or it could be a corporate IP network. In the case of the global Internet, there is no requirement that the sites all connect to the same Internetservice provider. The only requirement is that any of the sites isable to send IPv4 packets with protocol type 41 to any of the others. By definition, each site has an IPv6 prefix in the format defined in Section 2. It will therefore create DNS records for these addresses. For example, site A which owns IPv4 address 192.1.2.3 will create DNS records with the IPv6 prefix {FP=001,TLA=0x0002,NLA=192.1.2.3}/48(i.e., 2002:c001:0203::/48). Site B which owns address 9.254.253.252 will create DNS records with the IPv6 prefix{FP=001,TLA=0x0002,NLA=9.254.253.252}/48 (i.e., 2002:09fe:fdfc::/48). When an IPv6 host on site B queries the DNS entry for a host on site A, or otherwise obtains its address, it obtains an address with theprefix {FP=001,TLA=0x0002,NLA=192.1.2.3}/48 and whatever SLA andInterface ID applies. The converse applies when a host on site Aqueries the DNS for a host on site B. IPv6 packets are formed andtransmitted in the normal way within both sites._______________________________| || Wide Area IPv4 Network ||_______________________________|/ \192.1.2.3/ 9.254.253.252\_______________________________/_ ____________________\____________| / | | \ | |IPv4 Site A ########## | |IPv4 Site B ########## | | ____________________# 6to4 #_ | | ____________________# 6to4 #_ | || # router # || || # router # || ||IPv6 Site A ########## || ||IPv6 Site B ########## || ||2002:c001:0203::/48 || ||2002:09fe:fdfc::/48 || ||_______________________________|| ||_______________________________|| | | | | |_________________________________| |_________________________________| Within a 6to4 site, addresses with the 2002::/16 prefix, apart fromthose with the local 2002:V4ADDR::/48 prefix, will be handled likeany other non-local IPv6 address, i.e., by a default or explicitroute towards the 6to4 border router.Carpenter & Moore Standards Track [Page 8]When an outgoing packet reaches the 6to4 router, it is encapsulatedas defined in Section 3, according to the additional sending ruledefined in Section 5.3. Incoming packets are decapsulated according to the additional decapsulation rule defined in Section 5.3. Theadditional sending and decapsulation rules are the only changes toIPv6 forwarding, and they occur only at border routers. No IPv4routing information is imported into IPv6 routing (nor vice versa).In this scenario, any number of 6to4 sites can interoperate with notunnel configuration, and no special requirements from the IPv4service. All that is required is the appropriate DNS entries and the additional sending and decapsulation rules configured in the 6to4router. This router SHOULD also generate the appropriate IPv6 prefix announcements [CONF, DISC].Although site A and site B will each need to run IPv6 routinginternally, they do not need to run an IPv6 exterior routing protocol in this simple scenario; IPv4 exterior routing does the job for them. It is RECOMMENDED that in any case each site should use only one IPv4 address per 6to4 router, and that should be the address assigned tothe external interface of the 6to4 router. Single-homed sitestherefore SHOULD use only one IPv4 address for 6to4 routing. Multi- homed sites are discussed briefly in section 5.6.Because of the lack of configuration, and the distributed deployment model, there are believed to be no particular scaling issues with the basic 6to4 mechanism apart from encapsulation overhead.Specifically, it introduces no new entries in IPv4 routing tables.5.2 Mixed scenario with relay to native IPv6During the transition to IPv6 we can expect some sites to fit themodel just described (isolated sites whose only connectivity is theIPv4 Internet), whereas others will be part of larger islands ofnative or tunneled IPv6 using normal IPv6 TLA address space. The6to4 sites will need connectivity to these native IPv6 islands andvice versa. In the 6to4 model, this connectivity is accomplished by IPv6 routers which possess both 6to4 and native IPv6 addresses.Although they behave essentially as standard IPv6 routers, for thepurposes of this document they are referred to as relay routers todistinguish them from routers supporting only 6to4, or only nativeIPv6.There must be at least one router acting as a relay between the 6to4 domain and a given native IPv6 domain. There is nothing specialabout it; it is simply a normal router which happens to have at least Carpenter & Moore Standards Track [Page 9]one logical 6to4 pseudo-interface and at least one other IPv6interface. Since it is a 6to4 router, it implements the additionalsending and decapsulation rules defined in Section 5.3.We now have three distinct classes of routing domain to consider:1. the internal IPv6 routing domain of each 6to4 site;2. an exterior IPv6 routing domain interconnectinga given set of 6to4 border routers, including relay routers,among themselves, i.e., a 6to4 exterior routing domain;3. the exterior IPv6 routing domain of each native IPv6 island.1. The internal routing domain of a 6to4 site behaves as described in section 5.1.2. There are two deployment options for a 6to4 exterior routingdomain:2.1 No IPv6 exterior routing protocol is used. The 6to4 routersusing a given relay router each have a default IPv6 route pointing to the relay router. The relay router MAY apply source address basedfilters to accept traffic only from specific 6to4 routers.2.2 An IPv6 exterior routing protocol is used. The set of 6to4routers using a given relay router obtain native IPv6 routes from the relay router using a routing protocol such as BGP4+ [RFC 2283,BGP4+]. The relay router will advertise whatever native IPv6 routing prefixes are appropriate on its 6to4 pseudo-interface. Theseprefixes will indicate the regions of native IPv6 topology that therelay router is willing to relay to. Their choice is a matter ofrouting policy. It is necessary for network operators to carefullyconsider desirable traffic patterns and topology when choosing thescope of such routing advertisements. The relay router willestablish BGP peering only with specific 6to4 routers whose trafficit is willing to accept.Although this solution is more complex, it provides effective policy control, i.e., BGP4+ policy determines which 6to4 routers are able to use which relay router.3. A relay router MUST advertise a route to 2002::/16 into the native IPv6 exterior routing domain. It is a matter of routing policy howfar this routing advertisement of 2002::/16 is propagated in thenative IPv6 routing system. Since there will in general be multiple relay routers advertising it, network operators will require tofilter it in a managed way. Incorrect policy in this area will lead to potential unreachability or to perverse traffic patterns.Carpenter & Moore Standards Track [Page 10]6to4 prefixes more specific than 2002::/16 must not be propagated in native IPv6 routing, to prevent pollution of the IPv6 routing tableby elements of the IPv4 routing table. Therefore, a 6to4 site which also has a native IPv6 connection MUST NOT advertise its 2002::/48routing prefix on that connection, and all native IPv6 networkoperators MUST filter out and discard any 2002:: routing prefixadvertisements longer than /16.Sites which have at least one native IPv6 connection, in addition to a 6to4 connection, will therefore have at least one IPv6 prefix which is not a 2002:: prefix. Such sites’ DNS entries will reflect thisand DNS lookups will return multiple addresses. If two such sitesneed to interoperate, whether the 6to4 route or the native route will be used depends on IPv6 address selection by the individual hosts (or even applications).Now consider again the example of the previous section. Suppose anIPv6 host on site B queries the DNS entry for a host on site A, andthe DNS returns multiple IPv6 addresses with different prefixes.____________________________ ______________________ | | | | | Wide Area IPv4 Network | | Native IPv6 | | | | Wide Area Network | |____________________________| |______________________| / \ //192.1.2.3/ 9.254.253.252\ // 2001:0600::/48____________/_ ____________________\_________//_/ | | \ // |########## | |IPv4 Site B ########## |__# 6to4 #_ | | ____________________# 6to4 #_ |# router # || || # router # ||########## || ||IPv6 Site B ########## |||| ||2002:09fe:fdfc::/48 ||__Site A_____|| ||2001:0600::/48_________________||as before | | |______________| |_________________________________|If the host picks the 6to4 prefix according to some rule for multiple prefixes, it will simply send packets to an IPv6 address formed with the prefix {FP=001,TLA=0x0002,NLA=192.1.2.3}/48. It is essentialthat they are sourced from the prefix{FP=001,TLA=0x0002,NLA=9.254.253.252}/48 for two-way connectivity to be possible. The address selection mechanism of Section 2.1 willensure this.Carpenter & Moore Standards Track [Page 11]5.2.1 Variant scenario with ISP relayThe previous scenario assumes that the relay router is provided by a cooperative 6to4 user site. A variant of this is for an InternetService Provider, that already offers native IPv6 connectivity, tooperate a relay router. Technically this is no different from theprevious scenario; site B is simply an internal 6to4 site of the ISP, possibly containing only one system, i.e., the relay router itself.5.2.2 Summary of relay router configurationA relay router participates in IPv6 unicast routing protocols on its native IPv6 interface and may do so on its 6to4 pseudo-interface, but these are independent routing domains with separate policies, even if the same protocol, probably BGP4+, is used in both cases.A relay router also participates in IPv4 unicast routing protocols on its IPv4 interface used to support 6to4, but this is not furtherdiscussed here.On its native IPv6 interface, the relay router MUST advertise a route to 2002::/16. It MUST NOT advertise a longer 2002:: routing prefixon that interface. Routing policy within the native IPv6 routingdomain determines the scope of that advertisement, thereby limitingthe visibility of the relay router in that domain.IPv6 packets received by the relay router whose next hop IPv6 address matches 2002::/16 will be routed to its 6to4 pseudo-interface andtreated according to the sending rule of Section 5.1.5.2.2.1. BGP4+ not usedIf BGP4+ is not deployed in the 6to4 exterior routing domain (option 2.1 of Section 5.2), the relay router will be configured to acceptand relay all IPv6 traffic only from its client 6to4 sites. Each6to4 router served by the relay router will be configured with adefault IPv6 route to the relay router (for example, Site A’s default IPv6 route ::/0 would point to the relay router’s address underprefix 2002:09fe:fdfc::/48).5.2.2.2. BGP4+ usedIf BGP4+ is deployed in the 6to4 exterior routing domain (option 2.2 of Section 5.2), the relay router advertises IPv6 native routingprefixes on its 6to4 pseudo-interface, peering only with the 6to4routers that it serves. (An alternative is that these routes couldbe advertised along with IPv4 routes using BGP4 over IPv4, ratherthan by running a separate BGP4+ session.) The specific routes Carpenter & Moore Standards Track [Page 12]advertised depend on applicable routing policy, but they must bechosen from among those reachable through the relay router’s nativeIPv6 interface. In the simplest case, a default route to the wholeIPv6 address space could be advertised. When multiple relay routers are in use, more specific routing prefixes would be advertisedaccording to the desired routing policy. The usage of BGP4+ iscompletely standard so is not discussed further in this document.5.2.2.3. Relay router scalingRelay routers introduce the potential for scaling issues. In general a relay router should not attempt to serve more sites than any other transit router, allowing for the encapsulation overhead.5.2.3 Unwilling to relayIt may arise that a site has a router with both 6to4 pseudo-interfaces and native IPv6 interfaces, but is unwilling to act as arelay router. Such a site MUST NOT advertise any 2002:: routingprefix into the native IPv6 domain and MUST NOT advertise any native IPv6 routing prefixes or a default IPv6 route into the 6to4 domain.Within the 6to4 domain it will behave exactly as in the basic 6to4scenario of Section 5.1.5.3 Sending and decapsulation rulesThe only change to standard IPv6 forwarding is that every 6to4 router (and only 6to4 routers) MUST implement the following additionalsending and decapsulation rules.In the sending rule, "next hop" refers to the next IPv6 node that the packet will be sent to, which is not necessarily the finaldestination, but rather the next IPv6 neighbor indicated by normalIPv6 routing mechanisms. If the final destination is a 6to4 address, it will be considered as the next hop for the purpose of this rule.If the final destination is not a 6to4 address, and is not local, the next hop indicated by routing will be the 6to4 address of a relayrouter.ADDITIONAL SENDING RULE for 6to4 routersif the next hop IPv6 address for an IPv6 packetdoes match the prefix 2002::/16, anddoes not match any prefix of the local sitethenapply any security checks (see Section 8);encapsulate the packet in IPv4 as in Section 3,Carpenter & Moore Standards Track [Page 13]。