Connection of IPv6 Domains via IPv4 Clouds
RFC 3056
|
| Document |
Type |
|
RFC - Proposed Standard
(February 2001; Errata)
|
|
Last updated |
|
2013-03-02
|
|
Stream |
|
IETF
|
|
Formats |
|
plain text
pdf
html
bibtex
|
| Stream |
WG state
|
|
(None)
|
|
Document shepherd |
|
No shepherd assigned
|
| IESG |
IESG state |
|
RFC 3056 (Proposed Standard)
|
|
Consensus Boilerplate |
|
Unknown
|
|
Telechat date |
|
|
|
Responsible AD |
|
(None)
|
|
Send notices to |
|
(None)
|
Network Working Group B. Carpenter
Request for Comments: 3056 K. Moore
Category: Standards Track February 2001
Connection of IPv6 Domains via IPv4 Clouds
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2001). All Rights Reserved.
Abstract
This memo specifies an optional interim mechanism for IPv6 sites to
communicate with each other over the IPv4 network without explicit
tunnel setup, and for them to communicate with native IPv6 domains
via 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 IPv6
address prefix to any site that currently has at least one globally
unique IPv4 address, and specifies an encapsulation mechanism for
transmitting IPv6 packets using such a prefix over the global IPv4
network.
The motivation for this method is to allow isolated IPv6 domains or
hosts, attached to an IPv4 network which has no native IPv6 support,
to communicate with other such IPv6 domains or hosts with minimal
manual configuration, before they can obtain natuve IPv6
connectivity. It incidentally provides an interim globally unique
IPv6 address prefix to any site with at least one globally unique
IPv4 address, even if combined with an IPv4 Network Address
Translator (NAT).
Carpenter & Moore Standards Track [Page 1]
RFC 3056 Connection of IPv6 Domains via IPv4 Clouds February 2001
Table of Contents
1. 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 8
5.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. Introduction
This memo specifies an optional interim mechanism for IPv6 sites to
communicate with each other over the IPv4 network without explicit
tunnel setup, and for them to communicate with native IPv6 domains
Show full document text