Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)
RFC 5214
Document | Type |
RFC - Informational
(March 2008; No errata)
Obsoletes RFC 4214
Was draft-templin-rfc4214bis (gen)
|
|
---|---|---|---|
Authors | Tim Gleeson , Dave Thaler , Fred Templin | ||
Last updated | 2015-10-14 | ||
Stream | ISE | ||
Formats | plain text html pdf htmlized bibtex | ||
Stream | ISE state | (None) | |
Consensus Boilerplate | Unknown | ||
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 5214 (Informational) | |
Telechat date | |||
Responsible AD | Mark Townsley | ||
Send notices to | (None) |
Network Working Group F. Templin Request for Comments: 5214 Boeing Phantom Works Obsoletes: 4214 T. Gleeson Category: Informational Cisco Systems K.K. D. Thaler Microsoft Corporation March 2008 Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) Status of This Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. IESG Note The IESG thinks that this work is related to IETF work done in WG softwires, but this does not prevent publishing. Abstract The Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) connects dual-stack (IPv6/IPv4) nodes over IPv4 networks. ISATAP views the IPv4 network as a link layer for IPv6 and supports an automatic tunneling abstraction similar to the Non-Broadcast Multiple Access (NBMA) model. Templin, et al. Informational [Page 1] RFC 5214 ISATAP March 2008 Table of Contents 1. Introduction ....................................................2 2. Requirements ....................................................3 3. Terminology .....................................................3 4. Domain of Applicability .........................................4 5. Node Requirements ...............................................4 6. Addressing Requirements .........................................4 6.1. ISATAP Interface Identifiers ...............................4 6.2. ISATAP Interface Address Configuration .....................5 6.3. Multicast/Anycast ..........................................5 7. Automatic Tunneling .............................................5 7.1. Encapsulation ..............................................5 7.2. Handling ICMPv4 Errors .....................................5 7.3. Decapsulation ..............................................6 7.4. Link-Local Addresses .......................................6 7.5. Neighbor Discovery over Tunnels ............................6 8. Neighbor Discovery for ISATAP Interfaces ........................6 8.1. Conceptual Model of a Host .................................7 8.2. Router and Prefix Discovery - Router Specification .........7 8.3. Router and Prefix Discovery - Host Specification ...........7 8.3.1. Host Variables ......................................7 8.3.2. Potential Router List Initialization ................7 8.3.3. Processing Received Router Advertisements ...........8 8.3.4. Sending Router Solicitations ........................8 8.4. Neighbor Unreachability Detection ..........................9 9. Site Administration Considerations ..............................9 10. Security Considerations ........................................9 11. IANA Considerations ...........................................10 12. Acknowledgments ...............................................10 13. References ....................................................11 13.1. Normative References .....................................11 13.2. Informative References ...................................12 Appendix A. Modified EUI-64 Addresses in the IANA Ethernet Address Block ...........................................13 1. Introduction This document specifies a simple mechanism called the Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) that connects dual-stack (IPv6/IPv4) nodes over IPv4 networks. Dual-stack nodes use ISATAP to automatically tunnel IPv6 packets in IPv4, i.e., ISATAP views the IPv4 network as a link layer for IPv6. ISATAP enables automatic tunneling whether global or private IPv4 addresses are used, and it presents a Non-Broadcast Multiple Access (NBMA) abstraction similar to [RFC2491],[RFC2492],[RFC2529], and [RFC3056]. Templin, et al. Informational [Page 2] RFC 5214 ISATAP March 2008 The main objectives of this document are to: 1) describe the domain of applicability, 2) specify addressing requirements, 3) specify automatic tunneling using ISATAP, 4) specify the operation of IPv6 Neighbor Discovery over ISATAP interfaces, and 5) discuss Site Administration, Security, and IANA considerations. 2. Requirements The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in thisShow full document text