draft-ietf-ospf-transition-to-ospfv3-10.txt   draft-ietf-ospf-transition-to-ospfv3-11.txt 
Internet Draft I. Chen Internet Draft I. Chen
<draft-ietf-ospf-transition-to-ospfv3-10.txt> Ericsson <draft-ietf-ospf-transition-to-ospfv3-11.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 June 28, 2016 Expires in 6 months June 29, 2016
OSPFv3 over IPv4 for IPv6 Transition OSPFv3 over IPv4 for IPv6 Transition
<draft-ietf-ospf-transition-to-ospfv3-10.txt> <draft-ietf-ospf-transition-to-ospfv3-11.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 13 skipping to change at page 3, line 13
family when using OSPFv3 over IPv4. family when using OSPFv3 over IPv4.
Table of Contents Table of Contents
1. Introduction ....................................................3 1. Introduction ....................................................3
1.1. IPv4-only Use Case .........................................4 1.1. IPv4-only Use Case .........................................4
2. Terminology .....................................................5 2. Terminology .....................................................5
3. Encapsulation in IPv4 ...........................................5 3. Encapsulation in IPv4 ...........................................5
3.1. Source Address .............................................7 3.1. Source Address .............................................7
3.2. Destination ................................................7 3.2. Destination ................................................7
3.3. Operation over Virtual Link ................................7 3.3. OSPFv3 Header Checksum .....................................7
4. Security Considerations .........................................8 3.4. Operation over Virtual Link ................................8
5. IANA Considerations .............................................8 4. Management Considerations .......................................8
6. Acknowledgments .................................................8 4.1. Coexistence with OSPFv2 ....................................8
7. References ......................................................9 5. Security Considerations .........................................9
7.1. Normative References........................................9 6. IANA Considerations .............................................9
7.2. informative References......................................9 7. Acknowledgments .................................................9
8. References .....................................................10
8.1. Normative References.......................................10
8.2. informative References.....................................10
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
and IPv6 address families can be advertised using either IPv4 or IPv6 and IPv6 address families can be advertised using either IPv4 or IPv6
transport. Some IPv4-specific and IPv6-specific routing protocols transport. Some IPv4-specific and IPv6-specific routing protocols
skipping to change at page 7, line 46 skipping to change at page 7, line 46
the destination address field in the IPv4 packet MUST be 224.0.0.5. the destination address field in the IPv4 packet MUST be 224.0.0.5.
For an OSPFv3 over IPv4 packet to be sent to AllDRouters, the For an OSPFv3 over IPv4 packet to be sent to AllDRouters, the
destination address field in the IPv4 packet MUST be 224.0.0.6. destination address field in the IPv4 packet MUST be 224.0.0.6.
When an OSPF router sends a unicast OSPF packet over a connected When an OSPF router sends a unicast OSPF packet over a connected
interface, the destination of such an IP packet is the address interface, the destination of such an IP packet is the address
assigned to the receiving interface. Thus, a unicast OSPFv3 packet assigned to the receiving interface. Thus, a unicast OSPFv3 packet
transported in an IPv4 packet would specify the OSPFv3 neighbor's transported in an IPv4 packet would specify the OSPFv3 neighbor's
IPv4 address as the destination address. IPv4 address as the destination address.
3.3. Operation over Virtual Links 3.3. OSPFv3 Header Checksum
For IPv4 transport, the pseudo-header used in the checksum
calculation will contain the IPv4 source and destination addresses,
the OSPFv3 protocol ID, and the OSPFv3 length from the OSPFv3
header (Appendix A.3.1 [RFC5340]). The format is similar to the
UDP pseudo-header as described in [RFC768] and is illustrated in
Figure 3.
0 1 2 3
0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | Protocol (89) | OSPFv3 Packet Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Pseduo-header for OSPFv3 over IPv4.
3.4. Operation over Virtual Links
When an OSPF router sends an OSPF packet over a virtual link, the When an OSPF router sends an OSPF packet over a virtual link, the
receiving router is a router that might not be directly connected receiving router is a router that might not be directly connected
to the sending router. Thus, the destination IP address of the IP to the sending router. Thus, the destination IP address of the IP
packet must be a reachable unicast IP address for the virtual link packet must be a reachable unicast IP address for the virtual link
endpoint. Because IPv6 is the presumed Internet protocol and an endpoint. Because IPv6 is the presumed Internet protocol and an
IPv4 destination is not routable, the OSPFv3 address family IPv4 destination is not routable, the OSPFv3 address family
extension [RFC5838] specifies that only IPv6 address family virtual extension [RFC5838] specifies that only IPv6 address family virtual
links are supported. links are supported.
skipping to change at page 8, line 20 skipping to change at page 8, line 40
supported with IPv4 address families by simply setting the IPv4 supported with IPv4 address families by simply setting the IPv4
destination address to a reachable IPv4 unicast address for the destination address to a reachable IPv4 unicast address for the
virtual link endpoint. Hence, the restriction in Section 2.8 of virtual link endpoint. Hence, the restriction in Section 2.8 of
RFC 5838 [RFC5838] is relaxed since virtual links can now be RFC 5838 [RFC5838] is relaxed since virtual links can now be
supported for IPv4 address families as long as the transport is supported for IPv4 address families as long as the transport is
also IPv4. If IPv4 transport, as specified herein, is used for also IPv4. If IPv4 transport, as specified herein, is used for
IPv6 address families, virtual links cannot be supported. Hence, in IPv6 address families, virtual links cannot be supported. Hence, in
OSPF routing domains that require virtual links, the IP transport OSPF routing domains that require virtual links, the IP transport
MUST match the address family (IPv4 or IPv6). MUST match the address family (IPv4 or IPv6).
4. Security Considerations 4. Management Considerations
4.1. Coexistence with OSPFv2
Since OSPFv2 [RFC2328] and OSPFv3 over IPv4 as described herein use
exactly the same protocol and IPv4 addresses, OSPFv2 packets may be
delivered to the OSPFv3 process and vice versa. When this occurs,
the mismatched protocol packets will be dropped due to validation
of the version in the first octet of the OSPFv2/OSPFv3 protocol
header. Note that this will not prevent the packets from being
delivered to the correct protocol process as standard socket
implementations will deliver a copy to each socket matching the
selectors.
Implementations of OSPFv3 over IPv4 transport SHOULD implement
separate counters for a protocol mismatch and SHOULD provide means
to suppress the ospfIfRxBadPacket and ospfVirtIfRxBadPacket SNMP
notifications as described in [RFC4750] and the ospfv3IfRxBadPacket
and ospv3VirtIfRxBadPacket SNMP notifications as described in
[RFC5643] when an OSPFv2 packet is received by the OSPFv3 process
or vice versa.
5. Security Considerations
As described in [RFC4552], OSPFv3 uses IPsec [RFC4301] for As described in [RFC4552], OSPFv3 uses IPsec [RFC4301] for
authentication and confidentiality. Consequently, an OSPFv3 packet authentication and confidentiality. Consequently, an OSPFv3 packet
transported within an IPv4 packet requires IPsec to provide transported within an IPv4 packet requires IPsec to provide
authentication and confidentiality. Further work such as [ipsecospf] authentication and confidentiality. Further work such as [ipsecospf]
would be required to support IPsec protection for OSPFv3 over IPv4 would be required to support IPsec protection for OSPFv3 over IPv4
transport. transport.
An optional OSPFv3 Authentication Trailer [RFC7166] also has been An optional OSPFv3 Authentication Trailer [RFC7166] also has been
defined as an alternative to using IPsec. The calculation of the defined as an alternative to using IPsec. The calculation of the
skipping to change at page 8, line 46 skipping to change at page 9, line 41
the length of hash measured in octets. the length of hash measured in octets.
The processing of the optional Authentication Trailer is contained The processing of the optional Authentication Trailer is contained
entirely within the OSPFv3 protocol. In other words, each OSPFv3 entirely within the OSPFv3 protocol. In other words, each OSPFv3
router instance is responsible for the authentication, without router instance is responsible for the authentication, without
involvement from IPsec or any other IP layer function. Consequently, involvement from IPsec or any other IP layer function. Consequently,
except for calculation of the Apad value, transporting OSPFv3 packets except for calculation of the Apad value, transporting OSPFv3 packets
using IPv4 does not change the generation or validation of the using IPv4 does not change the generation or validation of the
optional OSPFv3 Authentication Trailer. optional OSPFv3 Authentication Trailer.
5. IANA Considerations 6. IANA Considerations
No actions are required from IANA as result of the publication of No actions are required from IANA as result of the publication of
this document. this document.
6. Acknowledgments 7. Acknowledgments
The authors would like to thank Alexander Okonnikov for his thorough The authors would like to thank Alexander Okonnikov for his thorough
review and valuable feedback. The authors would also like to thank review and valuable feedback. The authors would also like to thank
Wenhu Lu for acting as document shepherd. Wenhu Lu for acting as document shepherd.
7. References 8. References
7.1. Normative References 8.1. Normative References
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September
1981. 1981.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998. (IPv6) Specification", RFC 2460, December 1998.
[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
for IPv6", RFC 5340, July 2008. for IPv6", RFC 5340, July 2008.
skipping to change at page 9, line 34 skipping to change at page 10, line 31
R. Aggarwal, "Support of Address Families in OSPFv3", RFC R. Aggarwal, "Support of Address Families in OSPFv3", RFC
5838, April 2010. 5838, April 2010.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5309] Shen, N., Ed., and A. Zinin, Ed., "Point-to-Point [RFC5309] Shen, N., Ed., and A. Zinin, Ed., "Point-to-Point
Operation over LAN in Link State Routing Protocols", RFC Operation over LAN in Link State Routing Protocols", RFC
5309, October 2008. 5309, October 2008.
7.2. Informative References 8.2. Informative References
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
Border Gateway Protocol 4 (BGP-4)", RFC 4271, January Border Gateway Protocol 4 (BGP-4)", RFC 4271, January
2006. 2006.
[RFC5613] Zinin, A., Roy, A., Nguyen, L., Friedman, B., and D. [RFC5613] Zinin, A., Roy, A., Nguyen, L., Friedman, B., and D.
Yeung, "OSPF Link-Local Signaling", RFC 5613, August 2009. Yeung, "OSPF Link-Local Signaling", RFC 5613, August 2009.
[RFC826] Plummer, D., "Ethernet Address Resolution Protocol: Or [RFC826] Plummer, D., "Ethernet Address Resolution Protocol: Or
Converting Network Protocol Addresses to 48.bit Ethernet Converting Network Protocol Addresses to 48.bit Ethernet
Address for Transmission on Ethernet Hardware", STD 37, Address for Transmission on Ethernet Hardware", STD 37,
RFC 826, November 1982. RFC 826, November 1982.
[RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet
Networks", RFC 2464, December 1998. Networks", RFC 2464, December 1998.
[RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI
10.17487/RFC0768, August 1980.
[RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
(BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, DOI (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, DOI
10.17487/RFC5881, June 2010. 10.17487/RFC5881, June 2010.
[RFC4750] Joyal, D., Ed., Galecki, P., Ed., Giacalone, S., Ed.,
Coltun, R., and F. Baker, "OSPF Version 2 Management
Information Base", RFC 4750, DOI 10.17487/RFC4750,
December 2006.
[RFC5643] Joyal, D., Ed., and V. Manral, Ed., "Management
Information Base for OSPFv3", RFC 5643, DOI
10.17487/RFC5643, August 2009.
[RFC4552] Gupta, M. and N. Melam, "Authentication/Confidentiality [RFC4552] Gupta, M. and N. Melam, "Authentication/Confidentiality
for OSPFv3", RFC 4552, June 2006. for OSPFv3", RFC 4552, June 2006.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005. Internet Protocol", RFC 4301, December 2005.
[RFC7166] Bhatia, M., Manral, V., and A. Lindem, "Supporting [RFC7166] Bhatia, M., Manral, V., and A. Lindem, "Supporting
Authentication Trailer for OSPFv3", RFC 7166, March 2014. Authentication Trailer for OSPFv3", RFC 7166, March 2014.
[ipsecospf] Gupta, M. and Melam, M, Work in progress, "draft-gupta- [ipsecospf] Gupta, M. and Melam, M, Work in progress, "draft-gupta-
 End of changes. 13 change blocks. 
17 lines changed or deleted 75 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/