draft-ietf-ospf-transition-to-ospfv3-05.txt   draft-ietf-ospf-transition-to-ospfv3-06.txt 
Internet Draft I. Chen Internet Draft I. Chen
<draft-ietf-ospf-transition-to-ospfv3-05.txt> Ericsson <draft-ietf-ospf-transition-to-ospfv3-06.txt> Ericsson
Intended Status: Standards Track A. Lindem Intended Status: Standards Track A. Lindem
Updates: 5838 Cisco Updates: 5838 Cisco
R. Atkinson R. Atkinson
Consultant Consultant
Expires in 6 months May 23, 2016 Expires in 6 months May 23, 2016
OSPFv3 over IPv4 for IPv6 Transition OSPFv3 over IPv4 for IPv6 Transition
<draft-ietf-ospf-transition-to-ospfv3-05.txt> <draft-ietf-ospf-transition-to-ospfv3-06.txt>
Status of this Memo Status of this Memo
Distribution of this memo is unlimited. Distribution of this memo is unlimited.
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 3, line 14 skipping to change at page 3, line 14
Table of Contents Table of Contents
1. Introduction ....................................................3 1. Introduction ....................................................3
2. Terminology .....................................................4 2. Terminology .....................................................4
3. Encapsulation in IPv4 ...........................................4 3. Encapsulation in IPv4 ...........................................4
3.1. Source Address .............................................6 3.1. Source Address .............................................6
3.2. Destination ................................................6 3.2. Destination ................................................6
3.3. Operation over Virtual Link ................................6 3.3. Operation over Virtual Link ................................6
4. IPv4-only Use Case ..............................................7 4. IPv4-only Use Case ..............................................7
5. Security Considerations .........................................7 5. Security Considerations .........................................8
6. IANA Considerations .............................................8 6. IANA Considerations .............................................8
7. References ......................................................8 7. References ......................................................8
1. Introduction 1. Introduction
Using OSPFv3 [RFC5340] over IPv4 [RFC791] with the existing OSPFv3 Using OSPFv3 [RFC5340] over IPv4 [RFC791] with the existing OSPFv3
Address Family extension can simplify transition from an IPv4-only Address Family extension can simplify transition from an IPv4-only
routing domain to an IPv6 [RFC2460], or dual-stack routing domain. routing domain to an IPv6 [RFC2460], or dual-stack routing domain.
Dual-stack routing protocols, such as Border Gateway Protocol Dual-stack routing protocols, such as Border Gateway Protocol
[RFC4271], have an advantage during the transition, because both IPv4 [RFC4271], have an advantage during the transition, because both IPv4
skipping to change at page 6, line 18 skipping to change at page 6, line 18
address for the interface over which the packet is transmitted. address for the interface over which the packet is transmitted.
All OSPFv3 routers on the link SHOULD share the same IPv4 subnet All OSPFv3 routers on the link SHOULD share the same IPv4 subnet
for IPv4 transport to function correctly. for IPv4 transport to function correctly.
While OSPFv2 operates on a subnet, OSPFv3 operates on a link While OSPFv2 operates on a subnet, OSPFv3 operates on a link
[RFC5340]. Accordingly, an OSPFv3 router implementation MAY [RFC5340]. Accordingly, an OSPFv3 router implementation MAY
support adjacencies with OSPFv3 neighbors on different IPv4 support adjacencies with OSPFv3 neighbors on different IPv4
subnets. If this is supported, the IPv4 data plane MUST resolve subnets. If this is supported, the IPv4 data plane MUST resolve
the layer-2 address using Address Resolution Protocol (ARP) on the layer-2 address using Address Resolution Protocol (ARP) on
multi-access networks and point-to-point over LAN [RFC5309] for multi-access networks and point-to-point over LAN [RFC5309] for
direct next-hops on different IPv4 subnets direct next-hops on different IPv4 subnets.
3.2. Destination Address 3.2. Destination Address
As defined in OSPFv2, the IPv4 destination address of an OSPF As defined in OSPFv2, the IPv4 destination address of an OSPF
protocol packet is either an IPv4 multicast address or the IPv4 protocol packet is either an IPv4 multicast address or the IPv4
unicast address of an OSPFv2 neighbor. Two well-known link-local unicast address of an OSPFv2 neighbor. Two well-known link-local
multicast addresses are assigned to OSPFv2, the AllSPFRouters multicast addresses are assigned to OSPFv2, the AllSPFRouters
address (224.0.0.5) and the AllDRouters address (224.0.0.6). The address (224.0.0.5) and the AllDRouters address (224.0.0.6). The
multicast address used depends on the OSPF packet type, the OSPF multicast address used depends on the OSPF packet type, the OSPF
interface type, and the OSPF router's role on multi-access interface type, and the OSPF router's role on multi-access
 End of changes. 4 change blocks. 
4 lines changed or deleted 4 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/