IPV4 to IPV6: IPv4

Transition From IPv4 to IPv6

Tukiyooo 0 IPv4, IPv4/IPv6, IPv6, Transition 01:04

One problem in transition from <a href="http://ipv4-ipv6.blogspot.com/" target="_blank">IPv4 to IPv6</a> completely is that IPv6 
is not backward compatible. This results in a situation where either a 
site is on IPv6 or it is not. Unlike an implementation of new 
technology where the newer one is backward compatible so the older 
system can still work with the newer without any additional changes. 
To overcome this short-coming, there exist few technologies which can be used in slow and smooth transition from IPv4 to IPv6: 
<h2>
Dual Stack Routers</h2>
A router can be installed with both IPv4 and IPv6 addresses 
configured on its interfaces pointing to the network of relevant IP 
scheme. 
<figure>
<img caption="Dual Stack Router" src="http://www.tutorialspoint.com/ipv6/images/dual_stack_router.jpg" />
<figcaption align="center">[Image: Dual Stack Router]</figcaption>
</figure>In above diagram, a Server which is having IPv4 as well as IPv6 
address configured for it now can speak with all hosts on IPv4 network 
and IPv6 network with help of Dual Stack Router. Dual Stack Router, can
 communicate with both networks and provides a medium for hosts to 
access Server without changing their respective IP version. 
<h2>
Tunneling</h2>
In a scenario where different IP versions exist on intermediate path 
or transit network, tunneling provides a better solution where user’s 
data can pass through a non-supported IP version. 
<figure>
<img caption="Tunneling" src="http://www.tutorialspoint.com/ipv6/images/tunneling.jpg" />
<figcaption align="center">[Image: Tunneling]</figcaption>
</figure>The above diagram depicts how two remote IPv4 networks can 
communicate via Tunnel, where the transit network was on IPv6. Vice 
versa is also possible where transit network is on IPv6 and remote sites
 which intends to communicate, are on IPv4. 
<h2>
NAT Protocol Translation</h2>
This is another important method of transition to IPv6 by means of a 
NAT-PT (Network Address Translation – Protocol Translation) enabled 
device. With help of NAT-PT device, actual conversion happens between 
IPv4 and IPv6 packets and vice versa. See the diagram below: 
<figure>
<img caption="NAT-PT" src="http://www.tutorialspoint.com/ipv6/images/nat.jpg" />
<figcaption align="center">[Image: NAT - Protocol Translation]</figcaption>
</figure>

A host with IPv4 address sends a request to IPv6 enabled Server on 
Internet which does not understand IPv4 address. In this scenario, 
NAT-PT device can help them communicate. When IPv4 host sends a request
 packet to IPv6 Server, NAT-PT device/router, strips down the IPv4 
packet, removes IPv4 header and adds IPv6 header and passes it through 
the Internet. When a response from IPv6 Server comes for IPv4 host, the
 router does vice versa. 
http://ipv4-ipv6.blogspot.com/2014/07/one-problem-in-transition-from-ipv4-to.html

Transition From IPv4 to IPv6

One problem in transition from IPv4 to IPv6 completely is that IPv6 is not backward compatible. This results in a situation where either ...

What is IPv4 and IPv6 ?

Tukiyooo 0 IPv4, IPv4/IPv6, IPv6, Setup IPv6 01:02

<div class="_5pbx userContent" data-ft="{"tn":"K"}">
<a href="http://ipv4-ipv6.blogspot.com/" target="_blank">What is IPv4 and IPv6. ?</a> 
 Are you confused between IPv4 and IPv6 .Here I have listed the Differences between them. 
 IPv4 :- 1) All the addresses of IPv4 are 32 bit length 2)The support of IPsec is only Optional 3)The Senders and Forwarding Routers will do the Fragmentation 4) Broadcasts Messages are available too 5)Static of IP addresses or Dynamic configuration is required to Configure IP address 6)No Packet Flow identification 7) Internet group Management Protocol ( IGMP ) is used for the Multicast Group Membership. 
 IPv6:- 1) All the addresses of IPv4 are 128 bit length 2) Inbuilt IPsec Support 3) Only Sender will do the Fragmentation 4)) Broadcasts Messages are not available.Instead a Link local scope all nodes multi cast address is used for Broadcast 5)Auto configuration of Addresses is Available 6)Packet Flow identification is available within the IPv6 header Using the Flow Label Field 7) IGMP is replaced with the Neighbour Discovery Protocol. 
 Author: <a class="profileLink" href="https://www.facebook.com/1337vickz" rel="nofollow" target="_blank">Vicky singh</a></div>

What is IPv4 and IPv6 ?

What is IPv4 and IPv6. ? Are you confused between IPv4 and IPv6 .Here I have listed the Differences between them. IPv4 :- 1) All the ...

C++ Internet Protocol and Socket Address Classes

Tukiyooo 0 C++, Internet, IP address, IPv4, IPv4/IPv6, IPv6, Protocol, Socket 19:18

<pre>C++ Internet Protocol and Socket Address Classes

Document Number: TBD
Date: TBD
Author: Aleksandar Fabijanic <alex AT pocoproject.org>
 Günter Obiltschnig <guenter.obiltschnig AT appinf.com>

Content

1. Revision History

2. Motivation and Scope

3. IP Address
 3.1. Usage Examples
 3.1.1. IPv4
 3.1.2. IPv6
 3.2. Header <ip_address> synopsis

5. Socket Address
 5.1. Usage Examples
 5.2. Header <socket_address> synopsis

6. Conclusion

7. Acknowledgments

1. Revision History

- Oct 10 2012: created

2. Motivation and Scope

Given the pervasiveness of networking and Internet, there is a
pressing need for standard networking support in C++ language.
This proposal addresses the concerns of IP and socket addresses;
it is aimed to be one of the fundamental building blocks and
steps toward the Standard C++ Network Library goal.

This proposal is based on IP and socket address implementations
in the Net library in C++ Portable Components (POCO) [6] framework.
POCO framework has been open sourced in 2005 by its principal
sponsor (Applied Informatics Software Engineering GmbH) and is
currently licensed under Boost Software License and used in
production by numerous commercial entities as well as other
open source projects [7].

The scope of the proposal is description of functionality,
interfaces and usage examples for a set of classes providing
functionality to store and manipulate Internet Protocol
(IPv4 and v6) as well as socket (IP address + port) addresses.

3. IP Address

The ip_address class represents an Internet Protocol host
address. The address can belong to either IPv4 or IPv6 
(if the target platform supports it) address family.

Relational operators (==, !=, <, <=, >, >=) are supported. 
Notably, an IPv4 address is never equal to an IPv6 
address, even if the IPv6 address is IPv4 compatible and 
the addresses are logically the same.

For underlying IP address bit manipulation, bitwise operators
(&, |, ^, ~) are supported.

3.1 Usage Examples

3.1.1. IPv4:

ip_address ia("127.0.0.1");
assert (ia.family() == ip_address::ipv4);
assert (ia.to_string() == "127.0.0.1");
assert (ip.is_loopback());

ip_address addr("10.0.0.51");
ip_address mask(24, ip_address::ipv4);
assert(mask.prefix_len() == 24);

ip_address net = addr & mask;
assert(net.to_string() == "10.0.0.0");

ip_address host("0.0.0.51");
assert((net | host) == addr);
assert((~mask).to_string() == "0.0.0.255");

3.1.2. IPv6

ip_address ia("1080:0:0:0:8:600:200a:425c");
assert (ia.family() == ip_address::ipv6);
assert (ia.to_string() == "1080::8:600:200a:425c");

ip_address ia(62, ip_address::ipv6);
assert(ia.to_string() == "ffff:ffff:ffff:fffc::");

3.2. Header <ip_address> synopsis

namespace std {
namespace net {

typedef int socklen_t;

class ip_address {
public:
typedef std::vector<IPAddress> list;

enum family
/// Possible address families for IP addresses.
{
 ipv4
#ifdef _STD_HAVE_IPv6
 ,ipv6
#endif
};
 
ip_address();
 /// Creates a wildcard (zero) IPv4 ip_address.

ip_address(const ip_address& addr);
 /// Creates an ip_address by copying another one.

explicit IPAddress(family family);
 /// Creates a wildcard (zero) ip_address for the given address family.

explicit ip_address(const std::string& addr);
 /// Creates an IPAddress from the string containing
 /// an IP address in presentation format (dotted decimal
 /// for IPv4, hex string for IPv6).
 /// Depending on the format of addr, IPv4 or an IPv6 address is 
 /// created. See to_string() for details on the supported formats.
 /// Throws std::runtime_exception if the address cannot be parsed.

ip_address(const std::string& addr, Family family);
 /// Creates an ip_address from the string containing
 /// an IP address in presentation format (dotted decimal
 /// for IPv4, hex string for IPv6).

ip_address(const void* addr, socklen_t length);
 /// Creates an IPAddress from a native internet address.
 /// A pointer to an in_addr or an in6_addr structure may be passed.

ip_address(const void* addr, socklen_t length, uint32_t scope);
 /// Creates an IPAddress from a native internet address.
 /// A pointer to a in_addr or a in6_addr structure may be 
 /// passed. Additionally, for an IPv6 address, a scope ID
 /// may be specified. The scope ID will be ignored if an IPv4
 /// address is specified.

ip_address(uint32_t prefix, family family);
 /// Creates an ip_address mask with the given length of prefix.

ip_address(const struct sockaddr& sockaddr);
 /// Creates an ip_address from sockaddr structure.

~ip_address();
 /// Destroys the IPAddress.

ip_address& operator = (const ip_address& addr);
 /// Assigns an IPAddress.
  
void swap(ip_address& address);
 /// Swaps the IPAddress with another one.
  
family family() const;
 /// Returns the address family (ipv4 or ipv6) of the address.

uint32_t scope() const;
 /// Returns the IPv6 scope identifier of the address. Returns 0 if
 /// the address is an IPv4 address, or the address is an
 /// IPv6 address but does not have a scope identifier.

std::string to_string() const;
 /// Returns a string containing a representation of the address
 /// in presentation format.
 /// For IPv4 addresses the result will be in dotted-decimal (d.d.d.d) notation.
 /// The preferred form is x:x:x:x:x:x:x:x, where the 'x's are the hexadecimal 
 /// values of the eight 16-bit pieces of the address. This is the full form.
 /// Example: 1080:0:0:0:8:600:200a:425c
 /// It is not necessary to write the leading zeros in an individual field. 
 /// However, there must be at least one numeral in every field, except as 
 /// described below.
 /// It is common for IPv6 addresses to contain long strings of zero bits. 
 /// In order to make writing addresses containing zero bits easier, a special
  /// syntax is  available to compress the zeros. The use of "::" indicates multiple
 /// groups of 16-bits of zeros. 
 /// The "::" can only appear once in an address. The "::" can also be used to 
 /// compress the leading and/or trailing zeros in an address. 
 /// Example: 1080::8:600:200a:425c
 /// For dealing with IPv4 compatible addresses in a mixed environment,
 /// a special syntax is available: x:x:x:x:x:x:d.d.d.d, where the 'x's are the 
 /// hexadecimal values of the six high-order 16-bit pieces of the address, 
 /// and the 'd's are the decimal values of the four low-order 8-bit pieces of the 
 /// standard IPv4 representation address. Example: ::ffff:192.168.1.120
 /// If an IPv6 address contains a non-zero scope identifier, it is added
 /// to the string, delimited by a percent character. On Windows platforms,
 /// the numeric value (which specifies an interface index) is directly
 /// appended. On Unix platforms, the name of the interface corresponding
 /// to the index (interpretation of the scope identifier) is added.

bool is_wildcard() const;
 /// Returns true iff the address is a wildcard (all zero) address.
  
bool is_broadcast() const;
 /// Returns true iff the address is a broadcast address.
 /// Only IPv4 addresses can be broadcast addresses. In a broadcast
 /// address, all bits are one. For an IPv6 address, returns always false.
 
bool is_loopback() const;
 /// Returns true iff the address is a loopback address.
 /// For IPv4, the loopback address is 127.0.0.1.
 /// For IPv6, the loopback address is ::1.
 
bool is_multicast() const;
 /// Returns true iff the address is a multicast address.
 /// IPv4 multicast addresses are in the
 /// 224.0.0.0 to 239.255.255.255 range
 /// (the first four bits have the value 1110).
 /// IPv6 multicast addresses are in the
 /// FFxx:x:x:x:x:x:x:x range.
  
bool is_unicast() const;
 /// Returns true iff the address is a unicast address.
 /// An address is unicast if it is neither a wildcard,
 /// broadcast or multicast address.
  
bool is_link_local() const;
 /// Returns true iff the address is a link local unicast address.
 /// IPv4 link local addresses are in the 169.254.0.0/16 range,
 /// according to RFC 3927.
 /// IPv6 link local addresses have 1111 1110 10 as the first
 /// 10 bits, followed by 54 zeros.
  
bool is_site_local() const;
 /// Returns true iff the address is a site local unicast address.
 /// IPv4 site local addresses are in on of the 10.0.0.0/24,
 /// 192.168.0.0/16 or 172.16.0.0 to 172.31.255.255 ranges.
 /// Originally, IPv6 site-local addresses had FEC0/10 (1111 1110 11) 
 /// prefix (RFC 4291), followed by 38 zeros. Interfaces using  
 /// this mask are supported, but obsolete; RFC 4193 [3] prescribes
 /// fc00::/7 (1111 110) as local unicast prefix.
  
bool is_ipv4_compatible() const;
 /// Returns true iff the address is IPv4 compatible.
 /// For IPv4 addresses, this is always true.
 /// For IPv6, the address must be in the ::x:x range (the
 /// first 96 bits are zero).

bool is_ipv4_mapped() const;
 /// Returns true iff the address is an IPv4 mapped IPv6 address.
 /// For IPv4 addresses, this is always true.
 /// For IPv6, the address must be in the ::FFFF:x:x range.
 
bool is_well_known_mcast() const;
 /// Returns true iff the address is a well-known multicast address.
 /// For IPv4, well-known multicast addresses are in the 224.0.0.0/8 range.
 /// For IPv6, well-known multicast addresses are in the 
 /// FF0x:x:x:x:x:x:x:x range.
 
bool is_node_local_mcast() const;
 /// Returns true iff the address is a node-local multicast address.
 /// IPv4 does not support node-local addresses, thus the result is
 /// always false for an IPv4 address.
 /// For IPv6, node-local multicast addresses are in the
 /// FFx1:x:x:x:x:x:x:x range.
 
bool is_link_local_mcast() const;
 /// Returns true iff the address is a link-local multicast address.
 /// For IPv4, link-local multicast addresses are in the
 /// 224.0.0.0/24 range. Note that this overlaps with the range for well-known
 /// multicast addresses.
 /// For IPv6, link-local multicast addresses are in the
 /// FFx2:x:x:x:x:x:x:x range.

bool is_site_local_mcast() const;
 /// Returns true iff the address is a site-local multicast address.
 /// For IPv4, site local multicast addresses are in the 239.255.0.0/16 range.
 /// For IPv6, site-local multicast addresses are in the
 /// FFx5:x:x:x:x:x:x:x range.

bool is_org_local_mcast() const;
 /// Returns true iff the address is a organization-local multicast address.
 /// For IPv4, organization-local multicast addresses are in the
 /// 239.192.0.0/16 range.
 /// For IPv6, organization-local multicast addresses are in the
 /// FFx8:x:x:x:x:x:x:x range.

bool is_global_mcast() const;
 /// Returns true iff the address is a global multicast address.
 /// For IPv4, global multicast addresses are in the 
 /// 224.0.1.0 to 238.255.255.255 range.
 /// For IPv6, global multicast addresses are in the
 /// FFxF:x:x:x:x:x:x:x range.
 
bool operator == (const ip_address& addr) const;
 /// Returns true if IP addresses are equal.

bool operator != (const ip_address& addr) const;
 /// Returns true if IP addresses are not equal.

bool operator < (const ip_address& addr) const;
 /// Returns true if this IP address is lesser than addr.

bool operator <= (const ip_address& addr) const;
 /// Returns true if this IP address is lesser than or equal to addr.

bool operator >  (const ip_address& addr) const
 /// Returns true if this IP address is greater than addr.

bool operator >= (const ip_address& addr) const;
 /// Returns true if this IP address is greater than or equal to addr.

ip_address operator & (const ip_address& addr) const;
 /// Performs a bitwise ANd operation and returns result.

ip_address operator | (const ip_address& addr) const;
 /// Performs a bitwise OR operation and returns result.

ip_address operator ^ (const ip_address& addr) const;
 /// Performs a bitwise XOR operation and returns result.

ip_address operator ~ () const;
 /// Performs a bitwise NOT operation on this IP address and returns result.
  
socklen_t length() const;
 /// Returns the length in bytes of the internal socket address structure. 
  
const void* addr() const;
 /// Returns the internal address structure.
  
uint32_t af() const;
 /// Returns the address family (AF_INET or AF_INET6) of the address.

unit32_t prefix_len() const;
 /// Returns the prefix length.
  
void mask(const ip_address& mask);
 /// Masks the IP address using the given netmask, which is usually
 /// a IPv4 subnet mask. Only supported for IPv4 addresses.
 /// The new address is (address & mask).
  
void mask(const ip_address& mask, const ip_address& set);
 /// Masks the IP address using the given netmask, which is usually
 /// a IPv4 subnet mask. Only supported for IPv4 addresses.
 /// The new address is (address & mask) | (set & ~mask).
  
static ip_address assign(const std::string& addr);
 /// Creates an IPAddress from the string containing
 /// an IP address in presentation format (dotted decimal
 /// for IPv4, hex string for IPv6).
 /// Depending on the format of addr, either an IPv4 or
 /// an IPv6 address is created.
 /// See to_string() for details on the supported formats.
 /// Throws std::runtime_exception if the address cannot be parsed.

static bool try_assign(const std::string& addr, IPAddress& result);
 /// Tries to interpret the given address string as an
 /// IP address in presentation format (dotted decimal
 /// for IPv4, hex string for IPv6).
 /// Returns true and stores the IPAddress in result if the
 /// string contains a valid address.
 /// Returns false and leaves result unchanged otherwise.

static IPAddress wildcard(Family family = ipv4);
 /// Returns a wildcard IPv4 or IPv6 address.
  
static IPAddress broadcast();
 /// Returns a broadcast IPv4 address (255.255.255.255).
};
}} // namespace std::net

4. Socket Address

This class represents an internet (IP) endpoint/socket address. The address
can belong either to the IPv4 or the IPv6 address family and consists of a
host IP  address and a port number.

4.1 Usage Examples

socket_address wild;
assert (wild.host().is_wildcard());
assert (wild.port() == 0);

socket_address sa1("192.168.1.100", 100);
assert (sa1.host().to_string() == "192.168.1.100");
assert (sa1.port() == 100);

socket_address sa2("192.168.1.100", "100");
assert (sa2.host().to_string() == "192.168.1.100");
assert (sa2.port() == 100);

socket_address sa3("192.168.1.100", "ftp");
assert (sa3.host().to_string() == "192.168.1.100");
assert (sa3.port() == 21);

socket_address sa4("www.appinf.com", 80);
assert (sa4.host().toString() == "50.57.108.29");
assert (sa4.port() == 80);

4.2 Header <socket_address> synopsis

namespace std {
namespace net {
class socket_address
 /// This class represents an (IP) socket address.
 /// The address can belong either to the IPv4 or the IPv6 address
 /// family and consists of a host address and a port number.
{
public:
socket_address();
 /// Creates a wildcard (all zero) IPv4 socket_address.

socket_address(const ip_address& host, uint_16t port);
 /// Creates a socket_address from an IP address and a port number.

socket_address(const std::string& host, uint_16t port);
 /// Creates a socket_address from an IP address and a port number.
 /// The IP address must either be a domain name, or it must
 /// be in dotted decimal (IPv4) or hex string (IPv6) format.

socket_address(const std::string& host, const std::string& port);
 /// Creates a socket_address from an IP address and a
 /// service name or port number.
 /// The IP address must either be a domain name, or it must
 /// be in dotted decimal (IPv4) or hex string (IPv6) format.
 /// The given port must either be a decimal port number, or
 /// a service name (as typically returned in struct servent
 /// by the getservbyname() call.

explicit socket_address(const std::string& host_and_port);
 /// Creates a socket_address from an IP address or host name and a
 /// port number/service name. Host name/address and port number
 /// must be separated by a colon. In case of an IPv6 address, the
 /// address part must be enclosed in brackets.
 /// 
 /// Examples:
 ///     192.168.1.10:80
 ///     [::ffff:192.168.1.120]:2040
 ///     www.appinf.com:8080

socket_address(const socket_address& addr);
 /// Creates a socket_address by copying another one.

socket_address(const struct sockaddr* addr, socklen_t length);
 /// Creates a socket_address from a native socket address.

~socket_address();
 /// Destroys the socket_address.

socket_address& operator = (const socket_address& addr);
 /// Assigns another socket_address.

void swap(socket_address& addr);
 /// Swaps the socket_address with another one.

ip_address host() const;
 /// Returns the host IP address.

uint_16t port() const;
 /// Returns the port number.

socklen_t length() const;
 /// Returns the length of the internal native socket address.

const struct sockaddr* addr() const;
 /// Returns a pointer to the internal native socket address.

uint32_t af() const;
 /// Returns the address family (AF_INET or AF_INET6) of the address.

std::string to_string() const;
 /// Returns a string representation of the address.

ip_address::family family() const;
 /// Returns the address family of the host's address.

bool operator < (const socket_address& addr) const;
 /// Less than operator.

bool operator == (const socket_address& addr) const;
 /// Equal operator.

bool operator != (const socket_address& addr) const;
 /// Not equal operator.

};
}} // namespace std::net

6. Conclusion

Class interfaces for IP and socket address as well as rationale for their 
introduction in C++ Standard and usage examples were described in this 
proposal. This proposal is one of the starting points and building blocks 
for C++ Standard Networking Library. Implementation of the described 
functionality is currently available in POCO framework [6]; the 
implementation differs in naming scheme from this proposal. Given a 
positive feedback on the proposal, implementation  will be available 
in the near future as a standalone implementation in standard-compliant 
naming convention, with accompanying tests and code examples.

7. Acknowledgements

POCO original author (Günter Obiltschnig)
POCO project contributors and users

References

[1] RFC 791
[2] RFC 2460
[3] RFC 4193
[4] RFC 3513
[5] RFC 3879
[6] C++ Portable Components: http://pocoproject.org
[7] List of known POCO users: http://pocoproject.org/forum/viewtopic.php?f=11&t=3826

C++ Internet Protocol and Socket Address Classes

C++ Internet Protocol and Socket Address Classes Document Number: TBD Date: TBD Author: Aleksandar Fabijanic <alex AT pocoproject.or...

How to add IPv6 over IPv4 support to your network behind a NAT router

Tukiyooo 0 IPv4, IPv4/IPv6, IPv6, router, Setup IPv6 19:12

<pre>Firewall+IPv6 Tunnel mini-HOWTO
Hernán Freschi <hjf(at)hjf.com.ar>
version 0.1, 2002-11-27

How to add IPv6 over IPv4 support to your network behind a NAT router.
----------------------------------------------------------------------

Table of Contents

1. Introduction

1.1 Copyright
     1.2 Disclaimer
     1.3 Credits
     1.4 Changelog
  
  2. What's IPv6? What can it do for me?

3. How do I connect to the 6bone?

4. What should I allow through the firewall?

5. Configuring the IPv6 machines/routers

5.1. Linux

5.2. Windows

5.2.1 IPv6 stand-alone machine
    5.2.2 IPv6 network
      5.2.2.1 The Router
      5.2.2.2 The clients

6. Examples
     6.1 Windows PC using IPv6, behind iptables NAT/MASQ, with a tunnel from HE.
     6.2 Multiple Windows PCs using IPv6, behind iptables NAT/MASQ, with a tunnel from BTExact.

----------------------------------------------------------------------

1. Introduction

1.1 Copyright

This document is Copyright 2002 by Hernán Freschi. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.1 or any later version published by the Free Software Foundation with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license can be found at www.gnu.org.

1.2 Disclaimer 
Use the information in this document at your own risk. I disavow any potential liability for the contents of this document. Use of the concepts, examples, and/or other content of this document is entirely at your own risk.

All copyrights are owned by their owners, unless specifically noted otherwise. Use of a term in this document should not be regarded as affecting the validity of any trademark or service mark.

Naming of particular products or brands should not be seen as endorsements.

You are strongly recommended to take a backup of your system before major installation and backups at regular intervals.

1.3 Credits

Hernán Freschi <hjf(at)hjf.com.ar>

Microsoft, Windows, 2000, XP, SP1, .NET Server 2003 are all trademarks of Microsoft Corp.

Any comments or suggestions can be mailed to my mail address on: hjf(at)hjf.com.ar

This document is still in beta phase, so errors and omissions may be present.

1.4 Changelog

0.1 Initial Release.

Getting Started

2. What's IPv6? What can it do for me?

Sorry, that is beyond the scope of this document. This aims to make a iptables firewall to allow incoming traffic from an IPv6 tunnel.

3. How do I connect to the 6bone?

Through a tunnel broker!. Get your account (for free) at:

www.tunnelbroker.net (USA)
tb.ipv6.btexact.com (UK)
tb.ngnet.it (Italy?)

You could also use www.freenet6.net, but they use proprietary software, which doesn't run inside a network. But it's easier to implement and even assigns /48 subnets.

4. What should I allow through the firewall?

Everything that comes from the tunnel address, except ICMP (what for? let the linux box answer, so the packets dont get in the network). The rules I use are this:

iptables -A FORWARD -s <tunnel address> -p ! ICMP -i eth0 -j ACCEPT
iptables -t nat -A PREROUTING -i eth0 -j DNAT --to <internal router address>

And that's it. The outgoing packets don't need special treatment.

Note: This, of course, assumes that your Linux firewall doesn't handle the IPv6 packets. It's designed to run on tiny distros like FloppyFW (www.zelow.no/floppyfw) or LRP (www.lrp.org). With this, the firewall doesn't need support for IPv6. These packets are handled in an internal, more powerful (ie: with a hard disk) computer.

5. Configuring the IPv6 machines/routers

5.1 Linux

I don't have a linux box to experiment, you can either
a) Donate a hard disk, so I can install linux again or
b) Write this section for me :)

5.2 Windows (2000/XP/XP-SP1/.NET Server 2003 ONLY! Win9x is UNSUPPORTED).

First of all, you have to install IPv6 support:

C:\> ipv6 install
Installing...

Success.

5.2.1 IPv6 stand-alone machine:

Use your brokers script! If they didn't provide one, use these:

ipv6.exe rtu ::/0 2/::<tunnel address>
ipv6.exe adu 2/<your ipv6 address>

The 2/ is the Interface Index. It's usually 2, but it may vary. If in doubt, type

ipv6 if

and look for a line like this:

Interface 2: Automatic tunnel pseudo-interface

The number, obviously, is the one you are looking for.

5.2.2 IPv6 network

(Note: this applies only to the external network. If you need help setting up the IPv6 lan, read www.microsoft.com/ipv6)

5.2.2.1 The Router

Use your brokers script! If they didn't provide one, use these:

ipv6.exe rtu ::/0 2/::<tunnel address>
ipv6.exe adu 2/<your ipv6 address>
ipv6.exe rtu <your ipv6 subnet>/<your ipv6 netmask> 4 pub life 86400
ipv6.exe ifc 2 forw
ipv6.exe ifc 3 forw
ipv6.exe ifc 4 forw adv

2, 3, 4 are the interface indices. They may vary. To find out, type

ipv6 if

5.2.2.2 The clients

You don't need to do nothing, they are auto configured.

6. Examples:

6.1 Windows PC using IPv6, behind iptables NAT/MASQ, with a tunnel from HE.

Equipment required:
1 Box capable of running iptables (kernel = 2.4.x)
1 Box running Microsoft® Windows 2000, Windows XP (SP1), Windows .NET Server 2003.

Tunnel:
1 /127 Allocation from Hurricane Electric

+---+ +---+ \/\/\/\/\/ +------+ /\/\/\/\/\
 |WIN|------------|FFW|-----------/INTERNET\---------|TUNNEL|----------\ 6bone /
 +---+ +---+ \/\/\/\/\/ +------+ /\/\/\/\/\
10.42.42.100<->10.42.42.1 <-> 209.13.122.2 <-> ipv6.he.net <-> 2001:470:1F00:FFFF::xxxx

Configuration:
On the Linux box type:

iptables -A FORWARD -s 64.71.128.82 -p ! ICMP -i eth0 -j ACCEPT
iptables -t nat -A PREROUTING -s 64.71.128.82 -i eth0 -j DNAT --to 10.42.42.100

On the MS box type:

ipv6 rtu ::/0 2/::64.71.128.82 pub
ipv6 adu 2/2001:470:1F00:FFFF::xxxx

Congratulations. You are set.

Now try pinging to 6bone.net, for example.

6.2 Multiple Windows PCs using IPv6, behind iptables NAT/MASQ, with a tunnel from BTExact.

Equipment required:
1 Box capable of running iptables (kernel = 2.4.x)
n Boxes running Microsoft® Windows 2000, Windows XP (SP1), Windows .NET Server 2003.

Tunnel:
1 /64 Allocation from Hurricane Electric

+---+ +---+ +---+
  |WIN| |WIN| |WIN|
  +---+ +---+ +---+
    +-----+-----+
  +---+            +---+           \/\/\/\/\/         +------+          /\/\/\/\/\
--|WRT|------------|FFW|-----------/INTERNET\---------|TUNNEL|----------\  6bone /
  +---+            +---+           \/\/\/\/\/         +------+          /\/\/\/\/\

10.42.42.100<->10.42.42.1 <-> 209.13.122.2 <-> 193.113.58.80 <-> 2001:618:400::xxxx:xxxx

Configuration:
On the Linux box type:

iptables -A FORWARD -s 64.71.128.82 -p ! ICMP -i eth0 -j ACCEPT
iptables -t nat -A PREROUTING -s 64.71.128.82 -i eth0 -j DNAT --to 10.42.42.100

On the MS router type:

ipv6.exe rtu ::/0 2/::193.113.58.80
ipv6.exe adu 2/2001:618:400::xxxx:xxxx
ipv6.exe rtu 2001:618:400:xxxx::/64 4 pub life 86400
ipv6.exe ifc 2 forw
ipv6.exe ifc 3 forw
ipv6.exe ifc 4 forw adv

On the other machines type:

Nothing, they are auto configured. If they dont work, try:

ipv6 reset

If that doesn't work, check for a default route (::/0).

ipv6 rt

If there isn't one, try adding one:

ipv6 rtu ::/0 n/(your routers ipv6 address)

(where n is the interface index of the ethernet board connected to the network, usually 4).

If it works, but the next time you reboot, it does not auto configure, then maybe you are not publishing the default route in the router.

Congratulations. You are set.

Now try pinging to 6bone.net, for example. 
</pre>

How to add IPv6 over IPv4 support to your network behind a NAT router

Firewall+IPv6 Tunnel mini-HOWTO Hernán Freschi <hjf(at)hjf.com.ar> version 0.1, 2002-11-27 How to add IPv6 over IPv4 support to your ...

Converting IPv4 addresses to IPv6 addresses

Tukiyooo 0 Converting, Easy Explanation Of IPv4, Internet Protocol Version4 and IPv6, IPv4, IPv4/IPv6, Setup IPv6 19:08

Converting IPv4 addresses to IPv6 addresses
 
-------------------------------------------
 
Here's a cool tool for doing it in windows:
 
<a href="http://www.softpedia.com/get/network-tools/ip-tools/ipconvert.shtml" rel="nofollow">http://www.softpedia.com/get/Network-Tools/IP-Tools/IPConvert.shtml</a>

Here's the main ipv6 website:

There's a good read at Microsfoft on tcp/ip
 
fundamentals and subnetting:

<a href="http://www.microsoft.com/technet/itsolutions/network/evaluate/" rel="nofollow">http://www.microsoft.com/technet/itsolutions/network/evaluate/</a>
 
technol/tcpipfund/tcpipfund_ch04.mspx#EEIAG

Here are some OpenBSD related sites:

<a href="http://www.inet6.dk/config/openbsd.html" rel="nofollow">http://www.inet6.dk/config/openbsd.html</a>
 
<a href="http://www.sans.org/reading_room/whitepapers/firewalls/807.php" rel="nofollow">http://www.sans.org/reading_room/whitepapers/firewalls/807.php</a>

I'm sure there are scads more. Google is your friend! ;)

Here are a few more, more general or linux:

<a href="http://enterprisenetworkingplanet.com/netsp/article.php/3634596" rel="nofollow">http://enterprisenetworkingplanet.com/netsp/article.php/3634596</a>
 
<a href="http://enterprisenetworkingplanet.com/netsp/article.php/3629546" rel="nofollow">http://enterprisenetworkingplanet.com/netsp/article.php/3629546</a>
 
<a href="http://enterprisenetworkingplanet.com/netsp/article.php/3633211" rel="nofollow">http://enterprisenetworkingplanet.com/netsp/article.php/3633211</a>

The examples below are pretty simple Class C
 
network examples. I put several sequential
 
addresses in order to show the progression
 
in IPv6 notation.

--------------------------------------------
 
IPV4 Address: 192.168.1.100

IPV6 Address:

IPv6 Full Address
 
0000:0000:0000:0000:0000:0000:C0A8:0164

IPv6 Shorthand Adress:
 
::C0A8:0164

IPv6 & Dot Notation Full Address:
 
0000:0000:0000:0000:0000:0000:192.168.1.100

IPv6 & Dot Notation Shorthand Adress:
 
192.168.1.100
 
--------------------------------------------

--------------------------------------------
 
IPV4 Address: 192.168.1.101

IPV6 Address:

IPv6 Full Address
 
0000:0000:0000:0000:0000:0000:C0A8:0165

IPv6 Shorthand Adress:
 
::C0A8:0165

IPv6 & Dot Notation Full Address:
 
0000:0000:0000:0000:0000:0000:192.168.1.101

IPv6 & Dot Notation Shorthand Adress:
 
192.168.1.101
 
--------------------------------------------

--------------------------------------------
 
IPV4 Address: 192.168.1.102

IPV6 Address:

IPv6 Full Address
 
0000:0000:0000:0000:0000:0000:C0A8:0166

IPv6 Shorthand Adress:
 
::C0A8:0166

IPv6 & Dot Notation Full Address:
 
0000:0000:0000:0000:0000:0000:192.168.1.102

IPv6 & Dot Notation Shorthand Adress:
 
192.168.1.102
 
--------------------------------------------

--------------------------------------------
 
IPV4 Address: 192.168.1.103

IPV6 Address:

IPv6 Full Address
 
0000:0000:0000:0000:0000:0000:C0A8:0167

IPv6 Shorthand Adress:
 
::C0A8:0167

IPv6 & Dot Notation Full Address:
 
0000:0000:0000:0000:0000:0000:192.168.1.103

IPv6 & Dot Notation Shorthand Adress:
 
192.168.1.103
 
--------------------------------------------

--------------------------------------------
 
IPV4 Address: 192.168.1.104

IPV6 Address:

IPv6 Full Address
 
0000:0000:0000:0000:0000:0000:C0A8:0168

IPv6 Shorthand Adress:
 
::C0A8:0168

IPv6 & Dot Notation Full Address:
 
0000:0000:0000:0000:0000:0000:192.168.1.104

IPv6 & Dot Notation Shorthand Adress:
 
192.168.1.104
 
----------------------

Converting IPv4 addresses to IPv6 addresses

Converting IPv4 addresses to IPv6 addresses ------------------------------------------- Here's a cool tool for doing it in windows: h...

A Communication Mechanism between IPv4 and IPv6

Tukiyooo 0 Communication, Internet Protocol Version4 and IPv6, IPv4, IPv4/IPv6 19:02

<pre>Expires in six month K. Watanabe, Hitachi
 Y. Atarashi, Hitachi
 T. Miyamoto, Hitachi
 K. Yamamoto, NAIST
 J. Murai, Keio University

A Communication Mechanism between IPv4 and IPv6

<draft-tsuchiya-ipv4-ipv6-translator-00.txt>

Status of this Memo

This document is an Internet-Draft. Internet-Drafts are working
    documents of the Internet Engineering Task Force (IETF), its areas,
    and its working groups. Note that other groups may also distribute
    working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six
    months and may be updated, replaced, or obsoleted by other documents
    at any time.  It is inappropriate to use Internet-Drafts as
    reference material or to cite them other than as ``work in
    progress.''

To learn the current status of any Internet-Draft, please check the
    ``1id-abstracts.txt'' listing contained in the Internet-Drafts
    Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net
    (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
    Rim).

Abstract

In the late stage of the transition from IPv4 to IPv6, IPv4 lands
    are interconnected by IPv6 ocean and it is necessary for an IPv4
    node and an IPv6 to communicate directly. This memo proposes a
    mechanism to enable such direct communication with extension name
    servers, an address mapper, and translators for each IPv4 land.

1. Introduction

RFC1933 [TRANS-MECH] proposed mechanisms to transit IPv4 [IPv4] to
    IPv6 [IPv6], including dual stack and tunneling, for the early
    stage. IPv6 nodes are assumed to have IPv4 stack and IPv4 addresses.
    In the late stage of the transition, however, the space of IPv4

Tsuchiya      draft-tsuchiya-ipv4-ipv6-translator-00.txt      [Page 1]
 
INTERNET-DRAFT                                           November 1997

address will be exhausted. So, an IPv4 address cannot be assigned to
    dual-stack hosts. Moreover, IPv6-only hosts will appear for cost
    reasons. It is expected that IPv4 hosts will retain for a long time,
    even after appearance of IPv6-only hosts. Therefore, it is highly
    desired to develop a mechanism to enable a communication between an
    IPv4 host and an IPv6 host directly.

Though a header conversion mechanism is defined in [HDRCNV],
    interaction for an IPv4 host, an IPv6 host, a header conversion
    router, and name servers is not mentioned. This memo describes an
    entire scheme of direct communications between IPv4 hosts and IPv6
    hosts. The scheme is applicable to environments where there are
    multiple name servers and multiple site boundary routes thanks to
    one "address mapper".  It is not necessary to modify IPv4 hosts and
    IPv6 hosts.

This document uses the words defined in [IPV4], [IPV6], and
    [TRANS-MECH].

2. Components

In the late stage of the transition, IPv4 "land"s are interconnected
    by IPv6 "ocean". A set of IPv4-only nodes in an organization is an
    example of IPv6 island.

The proposed system consists of extension name servers, one address
    mapper, and translators. To implement communication between IPv4
    nodes and IPv6 nodes, each IPv4 island needs to install such
    components.

Extension name servers have both IPv4 stack and IPv6 stack and
    provides name service to IPv4 nodes and IPv6 nodes. Translators also
    have dual-stack functionality and translates "language" of IPv4
    nodes and that of IPv6 nodes. The address mapper is communicates
    only with the extension name servers and the translators.

Tsuchiya      draft-tsuchiya-ipv4-ipv6-translator-00.txt      [Page 2]
 
INTERNET-DRAFT                                           November 1997

Figure 1 illustrates an IPv4 land which installed the proposed
    system.

+---------+                                +-------- //
      |IPv4 node|                                |
      +----+----+                                |
           |                                     |
    +------+------+                              |
    |             |                              |
    |An IPv4 land |                              | IPv6 ocean
    |             |                              |
    |             |  +------------------------+  |         +---------+
    |             +--+ extension name servers +--+         |IPv6 node|
    |             |  +------------+-----------+  |         +---------+
    |             |               |              |
    |             |  +------------+-----------+  |         +---------+
    |             |  |   one address mapper   |  |         |IPv6 node|
    |             |  +------------+-----------+  |         +---------+
    |             |               |              |
    |             |  +------------+-----------+  |         +---------+
    |             +--+       translators      +--+         |IPv6 node|
    |             |  +------------------------+  |         +---------+
    |             |                              |
    +------+------+                              |
           |                                     |
      +----+----+                                |
      |IPv4 node|                                +-------- //
      +---------+

Figure 1

2.1 Translator between IPv4 and IPv6

The followings are examples of Translator between IPv4 and IPv6.

(1) Proxy gateway

An proxy gateway locates between an IPv4 host and an IPv6 host
        and establishes both an IPv4 connection to the IPv4 host and an
        IPv6 connection to the IPv6 host. The proxy gateway relays data
        from the IPv4 host to the IPv6 host and vice versa.

(2) Header conversion router

A header conversion router locates between an IPv4 host and an

Tsuchiya      draft-tsuchiya-ipv4-ipv6-translator-00.txt      [Page 3]
 
INTERNET-DRAFT                                           November 1997

IPv6 host. When the router receives an IPv4 packet, the router
        converts its IPv4 header to an IPv6 header then forwards it.
        When the router receives an IPv6 packet, the router converts its
        IPv6 header to an IPv4 header then fragments the packet if
        necessary and forwards it.

2.2 Extension Name Server

Extension name servers returns a "proper" answer in a response to
    IPv4 node's request or IPv6 node's request.

An IPv4 node typically requests one of extension name servers to
    resolve 'A' record correspond to a host name. If 'A' record is
    resolved, the server returns it. If only 'AAAA' record is available,
    the server requests an address mapper to assign one IPv4 address
    correspond to its IPv6 address. Then the server returns the assigned
    IPv4 address to the IPv4 node.

An IPv6 node typically requests one of extension name servers to
    resolve 'AAAA' record correspond to a host name. If 'AAAA' record is
    resolved, the server returns it. If only 'A' record is available,
    the server requests the address mapper to assign one IPv6 address
    correspond to its IPv4 address. Then the server returns the assigned
    IPv6 address to IPv6 node.

2.3 Address Mapper

An address mapper maintains an IPv4 address spool and an IPv6
    address spool. An example of the IPv4 address spool is private
    addresses(e.g number 10). An example of the IPv6 address spool is a
    part of IPv6 space assigned to the organization where the IPv4 land
    locates inside.

When an extension name server or a translator requests one IPv6
    address for an IPv4 address, the address mapper selects one IPv6
    address from the IPv6 address spool and returns it.

When an extension name server or a translator requests one IPv4
    address for an IPv6 address, the address mapper selects one IPv4
    address from the IPv4 address spool and returns it.

3. Interaction Examples

The following subsection explains communication from an IPv4 node to
    an IPv6 node and communication from an IPv6 node to an IPv4 node,
    respectively.

Tsuchiya      draft-tsuchiya-ipv4-ipv6-translator-00.txt      [Page 4]
 
INTERNET-DRAFT                                           November 1997

3.1 Communication from an IPv4 node to an IPv6 node

This subsection describes communication between an IPv4 node called
    "host4" and an IPv6 node called "host6". The communication is
    triggered by "host4".

"host4" sends a query to an extension name server to resolves 'A'
    record for "host6".

The extension name server tries resolving both 'A' record and 'AAAA'
    record for "host6" but only 'AAAA' record is resolved. Then the
    server requests an address mapper to assign one IPv4 address
    correspond to the IPv6 address.

The address mapper selects one IPv4 address out of its IPv4 address
    spool and returns it to the server.

The server creates 'A' record for the assigned IPv4 address and
    returns it to "host4".

"host4" sends IPv4 data to "host6".

The IPv4 data reaches a translator. The translator tries translating
    the IPv4 data to IPv6 data but does not know how to translate. (For
    example, a proxy gateway cannot create an IPv6 connection to "host6"
    since the IPv6 address of "host6" is not available.)  So, the
    translator requests the mapper to tell mapping entries for the IPv4
    source address and the IPv4 destination address.

The mapper looks up its mapping table with the IPv4 destination
    address and finds one IPv6 address for it. Then the mapper looks up
    its mapping table with the IPv4 source address. In this case, there
    is not a mapping entry so the mapper selects one IPv6 address for
    the IPv4 source address. Finally, the mapper returns a pair of the
    IPv6 source address and the IPv6 destination address to the
    translator.

The translator translates the IPv4 data to IPv6 data. (For example,
    the proxy gateway creates one IPv6 connection to "host6" and relay
    the IPv4 data.)

The IPv6 data reaches "host6". "host6" sends new IPv6 data to
    "host4".

The IPv6 data reaches the translator. This time the translator has
    mapping entries for the IPv6 source address and the IPv6 destination

Tsuchiya      draft-tsuchiya-ipv4-ipv6-translator-00.txt      [Page 5]
 
INTERNET-DRAFT                                           November 1997

address. The translator translates the IPv6 data to IPv4 data. (For
    example, the proxy gateway just relays the data.)

The IPv4 data reaches "host4".

The following diagram illustrates the interaction above:

IPv4    extension      address    translator    IPv6
        node    name server    mapper                   node
        "host4"                                         "host6"

Resolve an IPv4 address for host6

---> Query of 'A' record for "host6".

only 'AAAA' record is resolved.

---> Request one IPv4 address correspond to
                                the IPv6 address.

Assign on IPv4 address.

<--- Reply with the IPv4 address.

Create 'A' record for the IPv4 address.

<--- Reply with the 'A' record.

Tsuchiya      draft-tsuchiya-ipv4-ipv6-translator-00.txt      [Page 6]
 
INTERNET-DRAFT                                           November 1997

IPv4    extension      address    translator    IPv6
        node    name server    mapper                   node
        "host4"                                         "host6"

Send data to host6

=============================> IPv4 data

Try translating but don't
                                          know how to translate it.

<--- Request IPv6 addresses
 corresond to the IPv4 source
 address and to the IPv4
 destination address.

One IPv6 address correspond to the IPv4
                                destination address is already
                                available. Assign one IPv6 address for
                                the IPv4 source address.

---> Reply with the IPv6 source
                                           address and the IPv6
                                           destination address.

Translate IPv4 to IPv6.

===> IPv6 data

Reply data to
                                                        host4

<=== IPv6 data

Translate IPv6 to IPv4

<============================== IPv6 data

3.2 Communication from an IPv6 node to an IPv4 node

In a case where communication is triggered by "host6", its query to
    resolve 'AAAA' record for "host4" is eventually delivered to one of
    extension name servers. After interaction is symmetric to the case
    described in Sention 3.1.

Tsuchiya      draft-tsuchiya-ipv4-ipv6-translator-00.txt      [Page 7]
 
INTERNET-DRAFT                                           November 1997

4. Security Consideration

Header conversions of AH [AH] and ESP [ESP] are cryptographically
    impossible. This is a big disadvantage of header conversion router
    approach. On the other hand, it is possible to use AH and ESP in
    proxy gateway approach.

5. References

[AH] Stephen Kent and Randall Atkinson, "IP Authentication Header",
        Internet-Draft, July 1997.

[ESP] Stephen Kent and Randall Atkinson, "IP Encapsulating Security
        Payload (ESP)", Internet-Draft, July 1997.

[HDRCNV] Erik Nordmark, "IPv4/IPv6 Stateless Header Translator",
        Inernet-Draft, July 1997.

[IPV4] J. Postel, "Internet Protocol", RFC 791, September 1981.

[IPV6] S. Deering and R. Hinden, "Internet Protocol, Version 6
        (IPv6) Specification", RFC 1883, January 1996.

[TRANS-MECH] R. Gilligan and E. Nordmark, "Transition Mechanisms for
        IPv6 Hosts and Routers", RFC 1933, April 1996.

10. Author's Addresses

Kazuaki TSUCHIYA
    Hitachi, Ltd.
    Hitachi Systemplaza Shinkawasaki
    890 Kashimada, Saiwai, Kawasaki, 211 Japan

Phone: +81-44-549-1714
    Fax:   +81-44-549-1721
    Email: tsuchi@isrd.hitachi.co.jp

Munechika SUMIKAWA
    Office Systems Division, Hitachi, Ltd.
    810 Shimoimaizumi, Ebina-shi 243-04 JAPAN

Phone: +81-462-35-2111
    FAX:   +81-462-35-8325
    EMail: sumikawa@ebina.hitachi.co.jp

Tsuchiya      draft-tsuchiya-ipv4-ipv6-translator-00.txt      [Page 8]
 
INTERNET-DRAFT                                           November 1997

Ken WATANABE
    Hitachi, Ltd.
    Hitachi Systemplaza Shinkawasaki
    890 Kashimada, Saiwai, Kawasaki, 211 Japan

Phone: +81-44-549-1714
    Fax:   +81-44-549-1721
    Email: nabeken@isrd.hitachi.co.jp

Yoshifumi ATARASHI
    Office Systems Division, Hitachi, Ltd.
    810 Shimoimaizumi, Ebina-shi 243-04 JAPAN

Phone: +81-462-35-2111
    FAX:   +81-462-35-8325
    EMail: atarashi@ebina.hitachi.co.jp

Takahisa MIYAMOTO
    Hitachi, Ltd.
    Hitachi Systemplaza Shinkawasaki
    890 Kashimada, Saiwai, Kawasaki, 211 Japan

Phone: +81-44-549-1714
    Fax:   +81-44-549-1721
    Email: t-miyamo@isrd.hitachi.co.jp

Kazu YAMAMOTO
    Nara Institute of Science and Technology
    8916-5 Takayama, Ikoma City 630-01 JAPAN

Phone: +81-7437-2-5322
    FAX:   +81-7437-2-5329
    EMail: Kazu@Mew.org

Jun MURAI
    Keio University
    5322 Endo, Fujisawa 252 JAPAN

Phone: +81-466-47-5111
 Fax: +81-466-49-1101
 EMail: jun@wide.ad.jp</pre>

A Communication Mechanism between IPv4 and IPv6

Expires in six month K. Watanabe, Hitachi Y. Atarashi, Hi...

Use of VLANs for IPv4-IPv6 Coexistence in Enterprise Networks

Tukiyooo 0 Easy Explanation Of IPv4, IPv4, IPv4/IPv6, IPv6 18:59

Network Working Group                                           T. Chown 
Request for Comments: 4554                     University of Southampton 
Category: Informational                                        June 2006 
 
 
     Use of VLANs for IPv4-IPv6 Coexistence in Enterprise Networks 
 
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. 
 
Copyright Notice 
 
   Copyright (C) The Internet Society (2006). 
 
Abstract 
 
   Ethernet VLANs are quite commonly used in enterprise networks for the 
   purposes of traffic segregation.  This document describes how such 
   VLANs can be readily used to deploy IPv6 networking in an enterprise, 
   which focuses on the scenario of early deployment prior to 
   availability of IPv6-capable switch-router equipment.  In this 
   method, IPv6 may be routed in parallel with the existing IPv4 in the 
   enterprise and delivered at Layer 2 via VLAN technology.  The IPv6 
   connectivity to the enterprise may or may not enter the site via the 
   same physical link. 
 
Table of Contents 
 
   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 2 
   2.  Enabling IPv6 per Link  . . . . . . . . . . . . . . . . . . . . 3 
       2.1.  IPv6 Routing over VLANs . . . . . . . . . . . . . . . . . 3 
       2.2.  One VLAN per Router Interface . . . . . . . . . . . . . . 4 
       2.3.  Collapsed VLANs on a Single Interface . . . . . . . . . . 4 
       2.4.  Congruent IPv4 and IPv6 Subnets . . . . . . . . . . . . . 5 
       2.5.  IPv6 Addressing . . . . . . . . . . . . . . . . . . . . . 5 
       2.6.  Final IPv6 Deployment . . . . . . . . . . . . . . . . . . 5 
   3.  Example VLAN Topology . . . . . . . . . . . . . . . . . . . . . 6 
   4.  Security Considerations . . . . . . . . . . . . . . . . . . . . 7 
   5.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 7 
   6.  Informative References  . . . . . . . . . . . . . . . . . . . . 7 
   Appendix A.  Configuration Example  . . . . . . . . . . . . . . . . 8 
 
 
 
 
 
 
 
Chown                        Informational                      [Page 1] 
 
RFC 4554            VLANs for IPv4-IPv6 Coexistence            June 2006 
 
 
1.  Introduction 
 
   Ethernet VLANs are quite commonly used in enterprise networks for the 
   purposes of traffic segregation.  This document describes how such 
   VLANs can be readily used to deploy IPv6 networking in an enterprise, 
   including the scenario of early deployment prior to availability of 
   IPv6-capable switch-router equipment, where IPv6 may be routed in 
   parallel with the existing IPv4 in the enterprise and delivered to 
   the desired LANs via VLAN technology. 
 
   It is expected that in the long run, sites migrating to dual-stack 
   networking will either upgrade existing switch-router equipment to 
   support IPv6 or procure new equipment that supports IPv6.  If a site 
   already has production routers deployed that support IPv6, the 
   procedures described in this document are not required.  In the 
   interim, however, a method is required for early IPv6 adopters that 
   enables IPv6 to be deployed in a structured, managed way to some or 
   all of an enterprise network that currently lacks IPv6 support in its 
   core infrastructure. 
 
   The IEEE 802.1Q VLAN standard allows separate LANs to be deployed 
   over a single bridged LAN, by inserting "Virtual LAN" tagging or 
   membership information into Ethernet frames.  Hosts and switches that 
   support VLANs effectively allow software-based reconfiguration of 
   LANs through configuration of the tagging parameters.  The software 
   control means that VLANs can be used to alter the LAN infrastructure 
   without having to physically alter the wiring between the LAN 
   segments and Layer 3 routers. 
 
   Many IPv4 enterprise networks are utilising VLAN technology.  Where a 
   site does not have IPv6-capable Layer 2/3 switch-router equipment, 
   but VLANs are supported, a simple yet effective method exists to 
   gradually introduce IPv6 to some or all of that site's network, in 
   advance of the site's core infrastructure having dual-stack 
   capability. 
 
   If such a site wishes to introduce IPv6, it may do so by deploying a 
   parallel IPv6 routing infrastructure (which is likely to be a 
   different platform to the site's main infrastructure equipment, i.e., 
   one that supports IPv6 where the existing equipment does not), and 
   then using VLAN technology to "overlay" IPv6 links onto existing IPv4 
   links.  This can be achieved without needing any changes to the IPv4 
   configuration.  The VLANs don't need to differentiate between IPv4 
   and IPv6; the deployment is just dual-stack, as Ethernet is without 
   VLANs. 
 
 
 
 
 
 
Chown                        Informational                      [Page 2] 
 
RFC 4554            VLANs for IPv4-IPv6 Coexistence            June 2006 
 
 
   The IPv4 default route to the VLAN is provided by one (IPv4) router, 
   while the IPv6 default route to the VLAN is provided by a different 
   (IPv6) router.  The IPv6 router can provide native IPv6 connectivity 
   to the whole site with just a single physical interface, thanks to 
   VLAN tagging and trunking, as described below. 
 
   The IPv6 connectivity to the enterprise may or may not enter the site 
   via the same physical link as the IPv4 traffic, and may be native or 
   tunneled from the external provider to the IPv6 routing equipment. 
 
   This VLAN usage is a solution adopted by a number of sites already, 
   including that of the author. 
 
   It should be noted that a parallel infrastructure will require 
   additional infrastructure and thus cost, and will often require a 
   separate link into the site (from an IPv6 provider), quite possibly 
   tunneled, that will require the site's security policy to be applied 
   (e.g., firewalling and intrusion detection).  For sites that believe 
   early adoption of IPv6 is important, that price is one they may be 
   quite willing to pay.  However, this document focuses on the 
   technical issues of VLAN usage in such a scenario. 
 
2.  Enabling IPv6 per Link 
 
   The precise method by which IPv6 would be "injected" into the 
   existing IPv4 network is deployment specific.  For example, perhaps a 
   site has an IPv4-only router, connected to an Ethernet switch that 
   supports VLANs and a number of hosts connected to that VLAN.  Let's 
   further assume that the site has a dozen of these setups that it 
   wishes to IPv6-enable immediately.  This could be done by upgrading 
   the twelve routers to support IPv6, and turning IPv6 on those 
   routers.  However, this may not be practical for various reasons. 
 
   The simplest approach would be to connect an IPv6 router with one 
   interface to an Ethernet switch, and connect that switch to other 
   switches, and then use VLAN tags between the switches and the IPv6 
   router to "reach" all the IPv4-only subnets from the IPv6 router. 
   Thus, the general principle is that the IPv6 router device (e.g., 
   performing IPv6 Router Advertisements [1] in the case of stateless 
   autoconfiguration) is connected to the target link through the use of 
   VLAN-capable Layer 2 equipment. 
 
2.1.  IPv6 Routing over VLANs 
 
   In a typical scenario where connectivity is to be offered to a number 
   of existing IPv6 internal subnets, one IPv6 router could be deployed, 
   with both an external interface and one or more internal interfaces. 
   The external interface connects to the wider IPv6 internet, and may 
 
 
 
Chown                        Informational                      [Page 3] 
 
RFC 4554            VLANs for IPv4-IPv6 Coexistence            June 2006 
 
 
   be dual-stack if some tunnel mechanism is used for external 
   connectivity, or IPv6-only if a native external connection is 
   available. 
 
   The internal interface(s) can be connected directly to a VLAN-capable 
   switch.  It is then possible to write VLAN tags on the packets sent 
   from the internal router interface based on the target IPv6 link 
   prefix.  The VLAN-tagged traffic is then transported across the 
   internal VLAN-capable site infrastructure to the target IPv6 links 
   (which may be dispersed widely across the site network). 
 
   Where the IPv6 router is unable to VLAN-tag the packets, a protocol- 
   based VLAN can be created on the VLAN-capable device connected to the 
   IPv6 router, causing IPv6 traffic to be tagged and then redistributed 
   on (congruent) IPv4 subnet links that lie in the same VLAN. 
 
2.2.  One VLAN per Router Interface 
 
   The VLAN marking may be done in different ways.  Some sites may 
   prefer to use one router interface per VLAN; for example, if there 
   are three internal IPv6 links, a standard PC-based IPv6 router with 
   four Ethernet ports could be used, one for the external link and 
   three for the internal links.  In such a case, one switch port would 
   be needed per link, to receive the connectivity from each router 
   port. 
 
   In such a deployment, the IPv6 routing could be cascaded through 
   lower-tier internal IPv6-only routers.  Here, the internal-facing 
   ports on the IPv6 edge router may feed other IPv6 routers over IPv6- 
   only links, which in turn inject the IPv6 connectivity (the stub 
   links using 64-bit subnet prefixes and associated Router 
   Advertisements) into the VLANs. 
 
2.3.  Collapsed VLANs on a Single Interface 
 
   Using multiple IPv6 routers and one port per IPv6 link (i.e., VLAN) 
   may be unnecessary.  Many devices now support VLAN tagging based on 
   virtual interfaces such that multiple IPv6 VLANs could be assigned 
   (trunked) from one physical router interface port.  Thus, it is 
   possible to use just one router interface for "aggregated" VLAN 
   trunking from a switch.  This is a far more interesting case for a 
   site planning the introduction of IPv6 to (part of) its site network. 
 
   This approach is viable while the IPv6 traffic load is light.  As 
   traffic volume grows, the single collapsed interface could be 
   extended to utilise two or more physical ports, where the capacity of 
   the IPv6 router device allows it. 
 
 
 
 
Chown                        Informational                      [Page 4] 
 
RFC 4554            VLANs for IPv4-IPv6 Coexistence            June 2006 
 
 
2.4.  Congruent IPv4 and IPv6 Subnets 
 
   Such a VLAN-based technique can be used to deploy IPv6-only VLANs in 
   an enterprise network.  However, most enterprises will be interested 
   in dual-stack IPv4-IPv6 networking. 
 
   In such a case, the IPv6 connectivity may be injected into the 
   existing IPv4 VLANs, such that the IPv4 and IPv6 subnets are 
   congruent (i.e., they coincide exactly when superimposed).  Such a 
   method may have desirable administrative properties; for example, the 
   devices in each IPv4 subnet will be in the same IPv6 subnets also. 
   This is the method used at the author's site. 
 
   Furthermore, IPv6-only devices may be gradually added into the subnet 
   without any need to resize the IPv6 subnet (which may hold in effect 
   an infinite number of hosts in a /64 in contrast to IPv4 where the 
   subnet size is often relatively limited, or kept to a minimum 
   possibly due to address space usage concerns).  The lack of 
   requirement to periodically resize an IPv6 subnet is a useful 
   administrative advantage for IPv6. 
 
2.5.  IPv6 Addressing 
 
   One site using this VLAN technique has chosen to number its IPv6 
   links with the format [Site IPv6 prefix]:[VLAN ID]::/64.  The VLAN 
   tag is 16 bits, so this can work with a typical maximum 48-bit site 
   prefix.  Linking the VLAN ID into a site's addressing scheme may not 
   fit topology and aggregation, and thus is not necessarily a 
   recommended addressing plan, but some sites may wish to consider its 
   usage. 
 
2.6.  Final IPv6 Deployment 
 
   The VLAN technique for IPv6 deployment offers a more structured 
   alternative to opportunistic per-host intra-site tunnelling methods 
   such as Intra-Site Automatic Tunnel Addressing Protocol ISATAP [2]. 
   It has the ability to offer a simple yet efficient method for early 
   IPv6 deployment to an enterprise site. 
 
   When the site acquires IPv6-capable switch-router equipment, the 
   VLAN-based method can still be used for delivery of IPv6 links to 
   physical switch interfaces, just as it is commonly used today for 
   IPv4 subnets, but with a common routing infrastructure. 
 
 
 
 
 
 
 
 
Chown                        Informational                      [Page 5] 
 
RFC 4554            VLANs for IPv4-IPv6 Coexistence            June 2006 
 
 
3.  Example VLAN Topology 
 
   The following figure shows how a VLAN topology may be used to 
   introduce IPv6 in an enterprise network, using a parallel IPv6 
   routing infrastructure and VLAN tagging. 
 
                       External IPv6 Internet 
                                 | 
                                 | 
                        IPv6 Access Router 
                                 | 
                                 | 
                   Switch-router with VLAN support 
                                 | 
                                 | 
                  +--------------+----------------+ 
                  |Site enterprise infrastructure | 
                  |   with support for VLANs      | 
                  +----+--------------------+-----+ 
                       |                    | 
                       |                    | 
                 VLAN switch A         VLAN switch B 
                   |        |               | 
                   |        |               | 
               Subnet1    Subnet2        Subnet3 
 
         Figure 1: IPv6 deployment using VLANs (physical diagram) 
 
   In this scenario, the IPv6 access router has one physical port facing 
   toward the internal infrastructure.  In this example, it need only be 
   IPv6-enabled, as its purpose is solely to handle IPv6 traffic for the 
   enterprise.  The access router has an additional interface facing 
   toward the external infrastructure, which in this example could be 
   dual-stack if the external IPv6 connectivity is via a tunnel to an 
   IPv6 ISP. 
 
   A number of VLANs are handled by the internal-facing IPv6 router 
   port; in this case, IPv6 links Subnet1, Subnet2, Subnet3.  The VLANs 
   are seen as logical subinterfaces of the physical interface on the 
   IPv6 access router, which is using the "collapsed VLAN" method 
   described above, tagging the inbound traffic with one of three VLAN 
   IDs depending on the target IPv6 Subnet prefix. 
 
 
 
 
 
 
 
 
 
Chown                        Informational                      [Page 6] 
 
RFC 4554            VLANs for IPv4-IPv6 Coexistence            June 2006 
 
 
   The following figure shows how the IPv6 view of the deployment looks; 
   all IPv6 subnets are on-link to the IPv6 access router, whether or 
   not they share the same physical links over the VLAN infrastructure. 
 
                     External IPv6 Internet 
                                | 
                                | 
                     Site IPv6 Access Router 
                       |        |         | 
                       |        |         | 
                    Subnet1  Subnet2   Subnet3 
 
           Figure 2: IPv6 view of the deployment (logical view) 
 
   In this example, the router acts as an IPv6 first-hop access router 
   to the physical links, separately from the IPv4 first-hop router. 
   This technique allows a site to easily "inject" native IPv6 into all 
   the links where a VLAN-capable infrastructure is available, enabling 
   partial or full IPv6 deployment on the wire in a site. 
 
4.  Security Considerations 
 
   There are no additional security considerations particular to this 
   method of enabling IPv6 on a link. 
 
   Where the IPv6 connectivity is delivered into the enterprise network 
   by a different path from the IPv4 connectivity, care should be given 
   that equivalent application of security policy (e.g., firewalling) is 
   made to the IPv6 path. 
 
5.  Acknowledgements 
 
   The author would like to thank colleagues on the 6NET project, where 
   this technique for IPv4-IPv6 coexistence is widely deployed, in 
   particular Pekka Savola (CSC/FUNET), but also including Janos Mohacsi 
   (Hungarnet), Martin Dunmore and Chris Edwards (Lancaster University), 
   Christian Strauf (JOIN Project, University of Muenster), and Stig 
   Venaas (UNINETT). 
 
6.  Informative References 
 
   [1]  Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery 
        for IP Version 6 (IPv6)", RFC 2461, December 1998. 
 
   [2]  Templin, F., Gleeson, T., Talwar, M., and D. Thaler, "Intra-Site 
        Automatic Tunnel Addressing Protocol (ISATAP)", RFC 4214, 
        October 2005. 
 
 
 
 
Chown                        Informational                      [Page 7] 
 
RFC 4554            VLANs for IPv4-IPv6 Coexistence            June 2006 
 
 
Appendix A.  Configuration Example 
 
   This section describes a configuration example for using a computer 
   running the FreeBSD variant of the Berkeley Software Distribution 
   (BSD) operating system as a router to deploy IPv6 networking across a 
   number of IPv6 links on an enterprise (in this case, six links), for 
   a scenario similar to the one described above.  Here, the precise 
   configuration may of course vary depending on the existing site VLAN 
   deployment.  This section highlights that the VLAN configuration must 
   be manually configured; the support is not "automatic". 
 
   In this example, the configuration is for an IPv6 BSD router 
   connected directly to a site's external IPv6 access router.  The BSD 
   router has one interface (dc0) toward the site IPv6 access router, 
   and three interfaces (dc1, dc2, dc3) over which the internal routing 
   is performed (the number of interfaces can be varied; three are used 
   here to distribute the traffic load).  The IPv6 documentation prefix 
   (2001:db8::/32) is used in the example. 
 
--- Example IPv6 VLAN configuration, FreeBSD --- 
 
# 
# To IPv6 enable a vlan 
# 
# 1. Add a new vlan device to cloned_interfaces called vlanX 
# 
# 2. Add an ifconfig_vlanX line, the number is the vlan tag ID 
# 
# 3. Add vlanX to ipv6_network_interfaces 
# 
# 4. Add an ipv6_ifconfig_vlanX line, with a new unique prefix 
# 
# 5. Add vlanX to rtadvd_interface 
# 
# 6. Add vlanX to ipv6_router_flags 
 
### Interfaces ### 
 
# Bring physical interfaces up 
ifconfig_dc0="up" 
ifconfig_dc1="up" 
ifconfig_dc2="up" 
ifconfig_dc3="up" 
 
 
 
 
 
 
 
 
Chown                        Informational                      [Page 8] 
 
RFC 4554            VLANs for IPv4-IPv6 Coexistence            June 2006 
 
 
# Create VLan interfaces 
cloned_interfaces="vlan0 vlan1 vlan2 vlan3 vlan4 vlan5 vlan6" 
 
# Upstream link to IPv6 Access Router 
ifconfig_vlan0="vlan 37 vlandev dc0" 
 
# Downstream interfaces, load balance over interfaces dc1,dc2,dc3 
ifconfig_vlan1="vlan 11 vlandev dc1" # Subnet1 
ifconfig_vlan2="vlan 17 vlandev dc2" # Subnet2 
ifconfig_vlan3="vlan 24 vlandev dc3" # Subnet3 
ifconfig_vlan4="vlan 25 vlandev dc1" # Subnet4 
ifconfig_vlan5="vlan 34 vlandev dc2" # Subnet5 
ifconfig_vlan6="vlan 14 vlandev dc3" # Subnet6 
 
### IPv6 ### 
 
# Enable ipv6 
ipv6_enable="YES" 
 
# Forwarding 
ipv6_gateway_enable="YES" 
 
# Define Interfaces 
ipv6_network_interfaces="vlan0 vlan1 vlan2 vlan3 vlan4 vlan5 vlan6" 
# Define addresses 
ipv6_ifconfig_vlan0="2001:db8:d0:101::2 prefixlen 64" # Uplink 
ipv6_ifconfig_vlan1="2001:db8:d0:111::1 prefixlen 64" # Subnet1 
ipv6_ifconfig_vlan2="2001:db8:d0:112::1 prefixlen 64" # Subnet2 
ipv6_ifconfig_vlan3="2001:db8:d0:121::1 prefixlen 64" # Subnet3 
ipv6_ifconfig_vlan4="2001:db8:d0:113::1 prefixlen 64" # Subnet4 
ipv6_ifconfig_vlan5="2001:db8:d0:114::1 prefixlen 64" # Subnet5 
ipv6_ifconfig_vlan6="2001:db8:d0:115::1 prefixlen 64" # Subnet6 
 
# Router advertisements 
rtadvd_enable="YES" 
rtadvd_interfaces="-s vlan0 vlan1 vlan2 vlan3 vlan4 vlan5 vlan6" 
 
### Routing ### 
 
# Multicast 
mroute6d_enable="YES" 
mroute6d_program="/sbin/pim6sd" 
 
 
 
 
 
 
 
 
 
Chown                        Informational                      [Page 9] 
 
RFC 4554            VLANs for IPv4-IPv6 Coexistence            June 2006 
 
 
# RIP-ng 
ipv6_router_enable="YES" 
ipv6_router_flags="-N dc0,dc1,dc2,dc3, vlan1,vlan2,vlan3, 
                   vlan4,vlan5,vlan6" 
 
--- End of configuration --- 
 
   Note that if there was only one internal-facing interface, then again 
   so long as the OS supported VLAN trunking, all the VLAN IDs could be 
   associated to that interface (dc1, for example). 
 
   The VLAN IDs need to be managed by the site administrator, but would 
   probably already be assigned for existing IPv4 subnets (ones into 
   which IPv6 is being introduced). 
 
   For a large enterprise, a combination of internal tunnels and VLAN 
   usage could be used; the whole site need not be enabled by VLAN 
   tagging alone.  This choice is one for the site administrator to 
   make. 
 
Author's Address 
 
   Tim Chown 
   University of Southampton 
   Southampton, Hampshire  SO17 1BJ 
   United Kingdom 
 
   EMail: tjc@ecs.soton.ac.uk 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Chown                        Informational                     [Page 10] 
 
RFC 4554            VLANs for IPv4-IPv6 Coexistence            June 2006 
 
 
Full Copyright Statement 
 
   Copyright (C) The Internet Society (2006). 
 
   This document is subject to the rights, licenses and restrictions 
   contained in BCP 78, and except as set forth therein, the authors 
   retain all their rights. 
 
   This document and the information contained herein are provided on an 
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
 
Intellectual Property 
 
   The IETF takes no position regarding the validity or scope of any 
   Intellectual Property Rights or other rights that might be claimed to 
   pertain to the implementation or use of the technology described in 
   this document or the extent to which any license under such rights 
   might or might not be available; nor does it represent that it has 
   made any independent effort to identify any such rights.  Information 
   on the procedures with respect to rights in RFC documents can be 
   found in BCP 78 and BCP 79. 
 
   Copies of IPR disclosures made to the IETF Secretariat and any 
   assurances of licenses to be made available, or the result of an 
   attempt made to obtain a general license or permission for the use of 
   such proprietary rights by implementers or users of this 
   specification can be obtained from the IETF on-line IPR repository at 
   http://www.ietf.org/ipr. 
 
   The IETF invites any interested party to bring to its attention any 
   copyrights, patents or patent applications, or other proprietary 
   rights that may cover technology that may be required to implement 
   this standard.  Please address the information to the IETF at 
   ietf-ipr@ietf.org. 
 
Acknowledgement 
 
   Funding for the RFC Editor function is provided by the IETF 
   Administrative Support Activity (IASA). 
 
 
 
 
 
 
 
Chown                        Informational                     [Page 11]

Use of VLANs for IPv4-IPv6 Coexistence in Enterprise Networks

Network Working Group T. Chown Request for Comments: 4554 University of South...

IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) Protocol Specification

Tukiyooo 0 Infrastructures, Internet Protocol Version4 and IPv6, IPv4, IPv4/IPv6, IPv6, Protocol 18:53

<pre>

Internet Engineering Task Force (IETF)                       W. Townsley
Request for Comments: 5969                                      O. Troan
Category: Standards Track                                          Cisco
ISSN: 2070-1721                                              August 2010

IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) --
                         Protocol Specification

Abstract

This document specifies an automatic tunneling mechanism tailored to
   advance deployment of IPv6 to end users via a service provider's IPv4
   network infrastructure.  Key aspects include automatic IPv6 prefix
   delegation to sites, stateless operation, simple provisioning, and
   service, which is equivalent to native IPv6 at the sites that are
   served by the mechanism.

Status of This Memo

This is an Internet Standards Track document.

This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in Section 2 of RFC 5741.

Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   http://www.rfc-editor.org/info/rfc5969.

This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Townsley & Troan             Standards Track                    [Page 1]
 
RFC 5969                           6rd                       August 2010

Table of Contents

1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
   2.  Requirements Language  . . . . . . . . . . . . . . . . . . . .  4
   3.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   4.  6rd Prefix Delegation  . . . . . . . . . . . . . . . . . . . .  5
   5.  Troubleshooting and Traceability . . . . . . . . . . . . . . .  7
   6.  Address Selection  . . . . . . . . . . . . . . . . . . . . . .  7
   7.  6rd Configuration  . . . . . . . . . . . . . . . . . . . . . .  7
     7.1.  Customer Edge Configuration  . . . . . . . . . . . . . . .  8
       7.1.1.  6rd DHCPv4 Option  . . . . . . . . . . . . . . . . . .  9
     7.2.  Border Relay Configuration . . . . . . . . . . . . . . . . 10
   8.  Neighbor Unreachability Detection  . . . . . . . . . . . . . . 11
   9.  IPv6 in IPv4 Encapsulation . . . . . . . . . . . . . . . . . . 12
     9.1.  Maximum Transmission Unit  . . . . . . . . . . . . . . . . 13
     9.2.  Receiving Rules  . . . . . . . . . . . . . . . . . . . . . 13
   10. Transition Considerations  . . . . . . . . . . . . . . . . . . 14
   11. IPv6 Address Space Usage . . . . . . . . . . . . . . . . . . . 14
   12. Security Considerations  . . . . . . . . . . . . . . . . . . . 15
   13. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 16
   14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
   15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
     15.1. Normative References . . . . . . . . . . . . . . . . . . . 16
     15.2. Informative References . . . . . . . . . . . . . . . . . . 17

1.  Introduction

The original idea and the name of the mechanism (6rd) described in
   [RFC5569] details a successful commercial "rapid deployment" of the
   6rd mechanism by a residential service provider and is recommended
   reading.  This document describes the 6rd mechanism, which has been
   extended for use in more general environments.  Throughout this
   document, the term 6to4 is used to refer to the mechanism described
   in [RFC3056] and 6rd is the mechanism defined herein.

6rd specifies a protocol mechanism to deploy IPv6 to sites via a
   service provider's (SP's) IPv4 network.  It builds on 6to4 [RFC3056],
   with the key differentiator that it utilizes an SP's own IPv6 address
   prefix rather than a well-known prefix (2002::/16).  By using the
   SP's IPv6 prefix, the operational domain of 6rd is limited to the SP
   network and is under its direct control.  From the perspective of
   customer sites and the IPv6 Internet at large, the IPv6 service
   provided is equivalent to native IPv6.

The 6rd mechanism relies upon an algorithmic mapping between the IPv6
   and IPv4 addresses that are assigned for use within the SP network.
   This mapping allows for automatic determination of IPv4 tunnel
   endpoints from IPv6 prefixes, allowing stateless operation of 6rd.

Townsley & Troan             Standards Track                    [Page 2]
 
RFC 5969                           6rd                       August 2010

6rd views the IPv4 network as a link layer for IPv6 and supports an
   automatic tunneling abstraction similar to the Non-Broadcast Multiple
   Access (NBMA) [RFC2491] model.

A 6rd domain consists of 6rd Customer Edge (CE) routers and one or
   more 6rd Border Relays (BRs).  IPv6 packets encapsulated by 6rd
   follow the IPv4 routing topology within the SP network among CEs and
   BRs. 6rd BRs are traversed only for IPv6 packets that are destined to
   or are arriving from outside the SP's 6rd domain.  As 6rd is
   stateless, BRs may be reached using anycast for failover and
   resiliency (in a similar fashion to [RFC3068]).

On the "customer-facing" (i.e., "LAN") side of a CE, IPv6 is
   implemented as it would be for any native IP service delivered by the
   SP, and further considerations for IPv6 operation on the LAN side of
   the CE is out of scope for this document.  On the "SP-facing" (i.e.,
   "WAN") side of the 6rd CE, the WAN interface itself, encapsulation
   over Ethernet, ATM or PPP, as well as control protocols such as
   PPPoE, IPCP, DHCP, etc. all remain unchanged from current IPv4
   operation.  Although 6rd was designed primarily to support IPv6
   deployment to a customer site (such as a residential home network) by
   an SP, it can equally be applied to an individual IPv6 host acting as
   a CE.

6rd relies on IPv4 and is designed to deliver production-quality IPv6
   alongside IPv4 with as little change to IPv4 networking and
   operations as possible.  Native IPv6 deployment within the SP network
   itself may continue for the SP's own purposes while delivering IPv6
   service to sites supported by 6rd.  Once the SP network and
   operations can support fully native IPv6 access and transport, 6rd
   may be discontinued.

6rd utilizes the same encapsulation and base mechanism as 6to4 and
   could be viewed as a superset of 6to4 (6to4 could be achieved by
   setting the 6rd prefix to 2002::/16).  Unlike 6to4, 6rd is for use
   only in an environment where a service provider closely manages the
   delivery of IPv6 service. 6to4 routes with the 2002::/16 prefix may
   exist alongside 6rd in the 6rd CE router, and doing so may offer some
   efficiencies when communicating directly with 6to4 routers.

The 6rd link model can be extended to support IPv6 multicast.  IPv6
   multicast support is left for future consideration.

How this mechanism should be used and other deployment and
   operational considerations are considered out of scope for this
   document.

Townsley & Troan             Standards Track                    [Page 3]
 
RFC 5969                           6rd                       August 2010

2.  Requirements Language

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 RFC 2119 [RFC2119].

3.  Terminology

6rd prefix            An IPv6 prefix selected by the service provider
                         for use by a 6rd domain.  There is exactly one
                         6rd prefix for a given 6rd domain.  An SP may
                         deploy 6rd with a single 6rd domain or multiple
                         6rd domains.

6rd Customer Edge (6rd CE)  A device functioning as a Customer Edge
                               router in a 6rd deployment.  In a
                               residential broadband deployment, this
                               type of device is sometimes referred to
                               as a "Residential Gateway" (RG) or
                               "Customer Premises Equipment" (CPE).  A
                               typical 6rd CE serving a residential site
                               has one WAN side interface, one or more
                               LAN side interfaces, and a 6rd virtual
                               interface.  A 6rd CE may also be referred
                               to simply as a "CE" within the context of
                               6rd.

6rd delegated prefix  The IPv6 prefix calculated by the CE for use
                         within the customer site by combining the 6rd
                         prefix and the CE IPv4 address obtained via
                         IPv4 configuration methods.  This prefix can be
                         considered logically equivalent to a DHCPv6
                         IPv6 delegated prefix [RFC3633].

6rd domain            A set of 6rd CEs and BRs connected to the same
                         virtual 6rd link.  A service provider may
                         deploy 6rd with a single 6rd domain, or may
                         utilize multiple 6rd domains.  Each domain
                         requires a separate 6rd prefix.

CE LAN side           The functionality of a 6rd CE that serves the
                         "Local Area Network (LAN)" or "customer-facing"
                         side of the CE.  The CE LAN side interface is
                         fully IPv6 enabled.

Townsley & Troan             Standards Track                    [Page 4]
 
RFC 5969                           6rd                       August 2010

CE WAN side           The functionality of a 6rd CE that serves the
                         "Wide Area Network (WAN)" or "Service Provider-
                         facing" side of the CE.  The CE WAN side is
                         IPv4-only.

6rd Border Relay (BR) A 6rd-enabled router managed by the service
                         provider at the edge of a 6rd domain.  A Border
                         Relay router has at least one of each of the
                         following: an IPv4-enabled interface, a 6rd
                         virtual interface acting as an endpoint for the
                         6rd IPv6 in IPv4 tunnel, and an IPv6 interface
                         connected to the native IPv6 network.  A 6rd BR
                         may also be referred to simply as a "BR" within
                         the context of 6rd.

BR IPv4 address       The IPv4 address of the 6rd Border Relay for a
                         given 6rd domain.  This IPv4 address is used by
                         the CE to send packets to a BR in order to
                         reach IPv6 destinations outside of the 6rd
                         domain.

6rd virtual interface Internal multi-point tunnel interface where 6rd
                         encapsulation and decapsulation of IPv6 packets
                         inside IPv4 occurs.  A typical CE or BR
                         implementation requires only one 6rd virtual
                         interface.  A BR operating in multiple 6rd
                         domains may require more than one 6rd virtual
                         interface, but no more than one per 6rd domain.

CE IPv4 address       The IPv4 address given to the CE as part of
                         normal IPv4 Internet access (i.e., configured
                         via DHCP, PPP, or otherwise).  This address may
                         be global or private [RFC1918] within the 6rd
                         domain.  This address is used by a 6rd CE to
                         create the 6rd delegated prefix as well as to
                         send and receive IPv4-encapsulated IPv6
                         packets.

4.  6rd Prefix Delegation

The 6rd delegated prefix for use at a customer site is created by
   combining the 6rd prefix and all or part of the CE IPv4 address.
   From these elements, the 6rd delegated prefix is automatically
   created by the CE for the customer site when IPv4 service is
   obtained.  This 6rd delegated prefix is used in the same manner as a
   prefix obtained via DHCPv6 prefix delegation [RFC3633].

Townsley & Troan             Standards Track                    [Page 5]
 
RFC 5969                           6rd                       August 2010

In 6to4, a similar operation is performed by incorporating an entire
   IPv4 address at a fixed location following a well-known /16 IPv6
   prefix.  In 6rd, the IPv6 prefix as well as the position and number
   of bits of the IPv4 address incorporated varies from one 6rd domain
   to the next. 6rd allows the SP to adjust the size of the 6rd prefix,
   how many bits are used by the 6rd mechanism, and how many bits are
   left to be delegated to customer sites.  To allow for stateless
   address auto-configuration on the CE LAN side, a 6rd delegated prefix
   SHOULD be /64 or shorter.

The 6rd delegated prefix is created by concatenating the 6rd prefix
   and a consecutive set of bits from the CE IPv4 address in order.  The
   length of the 6rd delegated prefix is equal to length of the 6rd
   prefix (n) plus the number of bits from the CE IPv4 address (o).

The figure shows the format of an IPv6 address (Section 2.5.4 of
   [RFC4291]) with a 6rd prefix and an embedded CE IPv4 address:

Figure 1

For example, if the 6rd prefix is /32 and 24 bits of the CE IPv4
   address is used (e.g., all CE IPv4 addresses can be aggregated by a
   10.0.0.0/8), then the size of the 6rd delegated prefix for each CE is
   automatically calculated to be /56 (32 + 24 = 56).

Embedding less than the full 32 bits of a CE IPv4 address is possible
   only when an aggregated block of IPv4 addresses is available for a
   given 6rd domain.  This may not be practical with global IPv4
   addresses, but is quite likely in a deployment where private
   addresses are being assigned to CEs.  If private addresses overlap
   within a given 6rd deployment, the deployment may be divided into
   separate 6rd domains, likely along the same topology lines the NAT-
   based IPv4 deployment itself would require.  In this case, each
   domain is addressed with a different 6rd prefix.

Each 6rd domain may use a different encoding of the embedded IPv4
   address, even within the same service provider.  For example, if
   multiple IPv4 address blocks with different levels of aggregation are
   used at the same service provider, the number of IPv4 bits needed to
   encode the 6rd delegated prefix may vary between each block.  In this
   case, different 6rd prefixes, and hence separate 6rd domains, may be
   used to support the different encodings.

Townsley & Troan             Standards Track                    [Page 6]
 
RFC 5969                           6rd                       August 2010

Since 6rd delegated prefixes are selected algorithmically from an
   IPv4 address, changing the IPv4 address will cause a change in the
   IPv6 delegated prefix which would ripple through the site's network
   and could be disruptive.  As such, it is recommended that the service
   provider assign CE IPv4 addresses with relatively long lifetimes.

6rd IPv6 address assignment, and hence the IPv6 service itself, is
   tied to the IPv4 address lease; thus, the 6rd service is also tied to
   this in terms of authorization, accounting, etc.  For example, the
   6rd delegated prefix has the same lifetime as its associated IPv4
   address.  The prefix lifetimes advertised in Router Advertisements or
   used by DHCP on the CE LAN side MUST be equal to or shorter than the
   IPv4 address lease time.  If the IPv4 lease time is not known, the
   lifetime of the 6rd delegated prefix SHOULD follow the defaults
   specified in [RFC4861].

5.  Troubleshooting and Traceability

A 6rd IPv6 address and associated IPv4 address for a given customer
   can always be determined algorithmically by the service provider that
   operates the given 6rd domain.  This may be useful for referencing
   logs and other data at a service provider that may have more robust
   operational tools for IPv4 than IPv6.  This also allows IPv4 data
   path, node, and endpoint monitoring to be applicable to IPv6.

The 6rd CE and BR SHOULD support the IPv6 Subnet-Router anycast
   address [RFC4291] for its own 6rd delegated prefix.  This allows, for
   example, IPv6 ICMP echo messages to be sent to the 6rd virtual
   interface itself for additional troubleshooting of the internal
   operation of 6rd at a given CE or BR.  In the case of the BR, the
   IPv4 address used to calculate the 6rd delegated prefix is the
   configured BR IPv4 address.

6.  Address Selection

All addresses assigned from 6rd delegated prefixes should be treated
   as native IPv6.  No changes to the source address selection or
   destination address selection policy table [RFC3484] are necessary.

7.  6rd Configuration

For a given 6rd domain, the BR and CE MUST be configured with the
   following four 6rd elements.  The configured values for these four
   6rd elements are identical for all CEs and BRs within a given 6rd
   domain.

Townsley & Troan             Standards Track                    [Page 7]
 
RFC 5969                           6rd                       August 2010

IPv4MaskLen         The number of high-order bits that are identical
                       across all CE IPv4 addresses within a given 6rd
                       domain.  For example, if there are no identical
                       bits, IPv4MaskLen is 0 and the entire CE IPv4
                       address is used to create the 6rd delegated
                       prefix.  If there are 8 identical bits (e.g., the
                       Private IPv4 address range 10.0.0.0/8 is being
                       used), IPv4MaskLen is equal to 8 and IPv4MaskLen
                       high-order bits are stripped from the IPv4
                       address before constructing the corresponding 6rd
                       delegated prefix.

6rdPrefix           The 6rd IPv6 prefix for the given 6rd domain.

6rdPrefixLen        The length of the 6rd IPv6 prefix for the given
                       6rd domain.

6rdBRIPv4Address    The IPv4 address of the 6rd Border Relay for a
                       given 6rd domain.

7.1.  Customer Edge Configuration

The four 6rd elements are set to values that are the same across all
   CEs within a 6rd domain.  The values may be configured in a variety
   of manners, including provisioning methods such as the Broadband
   Forum's "TR-69" [TR069] Residential Gateway management interface, an
   XML-based object retrieved after IPv4 connectivity is established, a
   DNS record, an SMIv2 MIB [RFC2578], PPP IPCP, or manual configuration
   by an administrator.  This document describes how to configure the
   necessary parameters via a single DHCP option.  A CE that allows IPv4
   configuration by DHCP SHOULD implement this option.  Other
   configuration and management methods may use the format described by
   this option for consistency and convenience of implementation on CEs
   that support multiple configuration methods.

The only remaining provisioning information the CE requires in order
   to calculate the 6rd delegated prefix and enable IPv6 connectivity is
   an IPv4 address for the CE.  This CE IPv4 address is configured as
   part of obtaining IPv4 Internet access (i.e., configured via DHCP,
   PPP, or otherwise).  This address may be global or private [RFC1918]
   within the 6rd domain.

A single 6rd CE MAY be connected to more than one 6rd domain, just as
   any router may have more than one IPv6-enabled service provider
   facing interface and more than one set of associated delegated
   prefixes assigned by DHCPv6 prefix delegation or other means.  Each

Townsley & Troan             Standards Track                    [Page 8]
 
RFC 5969                           6rd                       August 2010

domain a given CE operates within would require its own set of 6rd
   configuration elements and would generate its own 6rd delegated
   prefix.

7.1.1.  6rd DHCPv4 Option

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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  OPTION_6RD   | option-length |  IPv4MaskLen  |  6rdPrefixLen |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                           6rdPrefix                           |
   |                          (16 octets)                          |
   |                                                               |
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     6rdBRIPv4Address(es)                      |
   .                                                               .
   .                                                               .
   .                                                               .
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 2

option-code         OPTION_6RD (212)

option-length       The length of the DHCP option in octets (22
                       octets with one BR IPv4 address).

IPv4MaskLen         The number of high-order bits that are identical
                       across all CE IPv4 addresses within a given 6rd
                       domain.  This may be any value between 0 and 32.
                       Any value greater than 32 is invalid.

6rdPrefixLen        The IPv6 prefix length of the SP's 6rd IPv6
                       prefix in number of bits.  For the purpose of
                       bounds checking by DHCP option processing, the
                       sum of (32 - IPv4MaskLen) + 6rdPrefixLen MUST be
                       less than or equal to 128.

6rdBRIPv4Address    One or more IPv4 addresses of the 6rd Border
                       Relay(s) for a given 6rd domain.

Townsley & Troan             Standards Track                    [Page 9]
 
RFC 5969                           6rd                       August 2010

6rdPrefix           The service provider's 6rd IPv6 prefix
                       represented as a 16-octet IPv6 address.  The bits
                       in the prefix after the 6rdPrefixlen number of
                       bits are reserved and MUST be initialized to zero
                       by the sender and ignored by the receiver.

The CE MUST include a Parameter Request List Option [RFC2132] for the
   OPTION_6RD.  Because the OPTION_6RD contains one IPv4MaskLen/
   6rdPrefixLen/6rdPrefix block, and because DHCP cannot convey more
   than one instance of an option, OPTION_6RD is limited to provision at
   most a single 6rd domain.  Provisioning of a CE router connected to
   multiple 6rd domains is outside the scope of this protocol
   specification.

The presence of the OPTION_6RD DHCP option is an indication of the
   availability of the 6rd service.  By default, receipt of a valid 6rd
   DHCP option by a 6rd-capable CE results in configuration of the 6rd
   virtual interface and associated delegated prefix for use on the CE's
   LAN side.  The CE MUST be able to configure the 6rd mechanism to be
   disabled, in which case the 6rd DHCP option, if received, is silently
   ignored.

A detailed description of CE behavior using multiple BR IPv4
   addresses is left for future consideration.  In such a case, a CE
   MUST support at least one BR IPv4 address and MAY support more than
   one.

When 6rd is enabled, a typical CE router will install a default route
   to the BR, a black hole route for the 6rd delegated prefix, and
   routes for any LAN side assigned and advertised prefixes.  For
   example, using a CE IPv4 address of 10.100.100.1, a BR IPv4 address
   of 10.0.0.1, an IPv4MaskLen of 8, 2001:db8::/32 as the 6rdPrefix, and
   one /64 prefix assigned to a LAN side interface, a typical CE routing
   table will look like:

::/0 -> 6rd-virtual-int0 via 2001:db8:0:100:: (default route)
     2001:db8::/32 -> 6rd-virtual-int0 (direct connect to 6rd)
     2001:db8:6464:100::/56 -> Null0 (delegated prefix null route)
     2001:db8:6464:100::/64 -> Ethernet0 (LAN interface)

7.2.  Border Relay Configuration

The 6rd BR MUST be configured with the same 6rd elements as the 6rd
   CEs operating within the same domain.

For increased reliability and load balancing, the BR IPv4 address may
   be an anycast address shared across a given 6rd domain.  As 6rd is
   stateless, any BR may be used at any time.  If the BR IPv4 address is

Townsley & Troan             Standards Track                   [Page 10]
 
RFC 5969                           6rd                       August 2010

anycast the relay MUST use this anycast IPv4 address as the source
   address in packets relayed to CEs.

Since 6rd uses provider address space, no specific routes need to be
   advertised externally for 6rd to operate, neither in IPv6 nor IPv4
   BGP.  However, if anycast is used for the 6rd IPv4 relays, the
   anycast addresses must be advertised in the service provider's IGP.

8.  Neighbor Unreachability Detection

Neighbor Unreachability Detection (NUD) for tunnels is described in
   Section 3.8 of [RFC4213].  In 6rd, all CEs and BRs can be considered
   as connected to the same virtual link and therefore neighbors to each
   other.  This section describes how to utilize neighbor unreachability
   detection without negatively impacting the scalability of a 6rd
   deployment.

A typical 6rd deployment may consist of a very large number of CEs
   within the same domain.  Reachability between CEs is based on IPv4
   routing, and sending NUD or any periodic packets between 6rd CE
   devices beyond isolated troubleshooting of the 6rd mechanism is NOT
   RECOMMENDED.

While reachability detection between a given 6rd CE and BR is not
   necessary for the proper operation of 6rd, in cases where a CE has
   alternate paths for BR reachability to choose from, it could be
   useful.  Sending NUD messages to a BR, in particular periodic
   messages from a very large number of CEs, could result in overloading
   of the BR control message processing path, negatively affecting
   scalability of the 6rd deployment.  Instead, a CE that needs to
   determine BR reachability MUST utilize a method that allows
   reachability detection packets to follow a typical data forwarding
   path without special processing by the BR.  One such method is
   described below.

1.  The CE constructs a payload of any size and content to be sent to
       the BR (e.g., a zero-length null payload, a padded payload
       designed to test a certain MTU, a NUD message, etc.).  The exact
       format of the message payload is not important as the BR will not
       be processing it directly.

2.  The desired payload is encapsulated with the inner IPv6 and outer
       IPv4 headers as follows:

*  The IPv6 destination address is set to an address from the
          CE's 6rd delegated prefix that is assigned to a virtual
          interface on the CE.

Townsley & Troan             Standards Track                   [Page 11]
 
RFC 5969                           6rd                       August 2010

*  The IPv6 source address is set to an address from the CE's 6rd
          delegated prefix as well, including the same as used for the
          IPv6 destination address.

*  The IPv4 header is then added as it normally would be for any
          packet destined for the BR.  That is, the IPv4 destination
          address is that of the BR, and the source address is the CE
          IPv4 address.

3.  The CE sends the constructed packet out the interface on which BR
       reachability is being monitored.  On successful receipt at the
       BR, the BR MUST decapsulate and forward the packet normally.
       That is, the IPv4 header is decapsulated normally, revealing the
       IPv6 destination as the CE, which in turn results in the packet
       being forwarded to that CE via the 6rd mechanism (i.e., the IPv4
       destination is that of the CE that originated the packet, and the
       IPv4 source is that of the BR).

4.  Arrival of the constructed IPv6 packet at the CE's IPv6 address
       completes one round trip to and from the BR, without causing the
       BR to process the message outside of its normal data forwarding
       path.  The CE then processes the IPv6 packet accordingly
       (updating keepalive timers, metrics, etc.).

The payload may be empty or could contain values that are meaningful
   to the CE.  Sending a proper NUD message could be convenient for some
   implementations (note that the BR will decrement the IPv6 hop limit).
   Since the BR forwards the packet as any other data packet without any
   processing of the payload itself, the format of the payload is left
   as a choice to the implementer.

9.  IPv6 in IPv4 Encapsulation

IPv6 in IPv4 encapsulation and forwarding manipulations (e.g.,
   handling packet markings, checksumming, etc.) is performed as
   specified in Section 3.5 of "Basic Transition Mechanisms for IPv6
   Hosts and Routers" [RFC4213], which is the same mechanism used by
   6to4 [RFC3056].  ICMPv4 errors are handled as specified in Section
   3.4 of [RFC4213].  By default, the IPv6 Traffic Class field MUST be
   copied to the IPv4 ToS (Type of Service) field.  This default
   behavior MAY be overridden by configuration.  See [RFC2983] and
   [RFC3168] for further information related to IP Differentiated
   Services and tunneling.

IPv6 packets from a CE are encapsulated in IPv4 packets when they
   leave the site via its CE WAN side interface.  The CE IPv4 address
   MUST be configured to send and receive packets on this interface.

Townsley & Troan             Standards Track                   [Page 12]
 
RFC 5969                           6rd                       August 2010

The 6rd link is modeled as an NBMA link similar to other automatic
   IPv6 in IPv4 tunneling mechanisms like [RFC5214], with all 6rd CEs
   and BRs defined as off-link neighbors from one other.  The link-local
   address of a 6rd virtual interface performing the 6rd encapsulation
   would, if needed, be formed as described in Section 3.7 of [RFC4213].
   However, no communication using link-local addresses will occur.

9.1.  Maximum Transmission Unit

Maximum transmission unit (MTU) and fragmentation issues for IPv6 in
   IPv4 tunneling are discussed in detail in Section 3.2 of RFC 4213
   [RFC4213]. 6rd's scope is limited to a service provider network.
   IPv4 Path MTU discovery MAY be used to adjust the MTU of the tunnel
   as described in Section 3.2.2 of RFC 4213 [RFC4213], or the 6rd
   Tunnel MTU might be explicitly configured.

The use of an anycast source address could lead to any ICMP error
   message generated on the path being sent to a different BR.
   Therefore, using dynamic tunnel MTU Section 3.2.2 of [RFC4213] is
   subject to IPv4 Path MTU blackholes.

Multiple BRs using the same anycast source address could send
   fragmented packets to the same IPv6 CE at the same time.  If the
   fragmented packets from different BRs happen to use the same fragment
   ID, incorrect reassembly might occur.  For this reason, a BR using an
   anycast source address MUST set the IPv4 Don't Fragment flag.

If the MTU is well-managed such that the IPv4 MTU on the CE WAN side
   interface is set so that no fragmentation occurs within the boundary
   of the SP, then the 6rd Tunnel MTU should be set to the known IPv4
   MTU minus the size of the encapsulating IPv4 header (20 bytes).  For
   example, if the IPv4 MTU is known to be 1500 bytes, the 6rd Tunnel
   MTU might be set to 1480 bytes.  Absent more specific information,
   the 6rd Tunnel MTU SHOULD default to 1280 bytes.

9.2.  Receiving Rules

In order to prevent spoofing of IPv6 addresses, the 6rd BR and CE
   MUST validate the embedded IPv4 source address of the encapsulated
   IPv6 packet with the IPv4 source address it is encapsulated by
   according to the configured parameters of the 6rd domain.  If the two
   source addresses do not match, the packet MUST be dropped and a
   counter incremented to indicate that a potential spoofing attack may
   be underway.  Additionally, a CE MUST allow forwarding of packets
   sourced by the configured BR IPv4 address.

Townsley & Troan             Standards Track                   [Page 13]
 
RFC 5969                           6rd                       August 2010

By default, the CE router MUST drop packets received on the 6rd
   virtual interface (i.e., after decapsulation of IPv4) for IPv6
   destinations not within its own 6rd delegated prefix.

10.  Transition Considerations

An SP network can migrate to IPv6 at its own pace with little or no
   effect on customers being provided IPv6 via 6rd.  When native IPv6
   connectivity is available, an administrator can choose to disable
   6rd.

The SP can choose to provision a separate IPv6 address block for
   native service, or reuse the 6rd prefix block itself.  If the SP uses
   a separate address block, moving from 6rd to native IPv6 is seen as a
   normal IPv6 renumbering event for the customer.  Renumbering may also
   be avoided by injecting the 6rd delegated prefix into the SP's IPv6
   routing domain.  Further considerations with regards to transitioning
   from 6rd to native IPv6 are not covered in this protocol
   specification.

11.  IPv6 Address Space Usage

As 6rd uses service-provider address space, 6rd uses the normal
   address delegation a service provider gets from its Regional Internet
   Registry (RIR) and no global allocation of a single 6rd IANA-assigned
   address block like the 6to4 2002::/16 is needed.

The service provider's prefix must be short enough to encode the
   unique bits of all IPv4 addresses within a given 6rd domain and still
   provide enough IPv6 address space to the residential site.  Assuming
   a worst case scenario using the full 32 bits for the IPv4 address,
   assigning a /56 for customer sites would mean that each service
   provider using 6rd would require a /24 for 6rd in addition to other
   IPv6 addressing needs.  Assuming that 6rd would be stunningly
   successful and taken up by almost all Autonomous System (AS) number
   holders (32K today), then the total address usage of 6rd would be
   equivalent to a /9.  If the SP instead delegated /60s to sites, the
   service provider would require a /28, and the total global address
   consumption by 6rd would be equivalent to a /13.  Again, this assumes
   that 6rd is used by all AS number holders in the IPv4 Internet today
   at the same time, that none have used any of 6rd's address
   compression techniques, and that none have moved to native IPv6 and
   reclaimed the 6rd space that was being used for other purposes.

To alleviate concerns about address usage, 6rd allows for leaving out
   redundant IPv4 prefix bits in the encoding of the IPv4 address inside
   the 6rd IPv6 address.  This is most useful where the IPv4 address
   space is very well aggregated.  For example, to provide each customer

Townsley & Troan             Standards Track                   [Page 14]
 
RFC 5969                           6rd                       August 2010

with a /60, if a service provider has all its IPv4 customers under a
   /12 then only 20 bits needs to be used to encode the IPv4 address and
   the service provider would only need a /40 IPv6 allocation for 6rd.
   If private address space is used, then a 10/8 would require a /36.
   If multiple 10/8 domains are used, then up to 16 could be supported
   within a /32.

If a service provider has a non-aggregatable IPv4 space and requiring
   the use of the full 32-bit IPv4 address in the encoding of the 6rd
   IPv6 address, the 6rd prefix MUST be no longer than /32 in order to
   offer a 6rd delegated prefix of at least /64.

The 6rd address block can be reclaimed when all users of it have
   transitioned to native IPv6 service.  This may require renumbering of
   customer sites and use of additional address space during the
   transition period.

12.  Security Considerations

A 6to4 relay router as specified in [RFC3056] can be used as an open
   relay.  It can be used to relay IPv6 traffic and as a traffic
   anonymizer.  By restricting the 6rd domain to within a provider
   network, a CE only needs to accept packets from a single or small set
   of known 6rd BR IPv4 addresses.  As such, many of the threats against
   6to4 as described in [RFC3964] do not apply.

When applying the receiving rules in Section 9.2, IPv6 packets are as
   well protected against spoofing as IPv4 packets are within an SP
   network.

A malicious user that is aware of a 6rd domain and the BR IPv4
   address could use this information to construct a packet that would
   cause a Border Relay to reflect tunneled packets outside of the
   domain that it is serving.  If the attacker constructs the packet
   accordingly and can inject a packet with an IPv6 source address that
   looks as if it originates from within another 6rd domain, forwarding
   loops between 6rd domains may be created, allowing the malicious user
   to launch a packet amplification attack between 6rd domains
   [RoutingLoop].

One possible mitigation for this is to simply not allow the BR IPv4
   address to be reachable from outside the SP's 6rd domain.  In this
   case, carefully constructed IPv6 packets still could be reflected off
   a single BR, but the looping condition will not occur.  Tunneled
   packets with the BR IPv4 address as the source address might also be
   filtered to prohibit 6rd tunnels from exiting the 6rd domain.

Townsley & Troan             Standards Track                   [Page 15]
 
RFC 5969                           6rd                       August 2010

To avoid forwarding loops via other internal relays, the BR should
   employ outgoing and incoming IPv4 packets filters, filtering out all
   known relay addresses for internal 6rd BRs, ISATAP routers, or 6to4
   relays, including the well-known anycast address space for 6to4.

Another possible mitigation to the routing loop issue is described in
   [V6OPS-LOOPS].

The BR MUST install a null route [RFC4632] for its 6rd delegated
   prefix created based on its BR IPv4 address, with the exception of
   the IPv6 Subnet-Router anycast address.

13.  IANA Considerations

IANA assigned a new DHCP Option code point for OPTION_6RD (212) with
   a data length of 18 + N (OPTION_6RD with N/4 6rd BR addresses).

14.  Acknowledgements

This RFC is based on Remi Despres' original idea described in
   [RFC5569] and the work done by Rani Assaf, Alexandre Cassen, and
   Maxime Bizon at Free Telecom.  Brian Carpenter and Keith Moore
   documented 6to4, which all of this work is based upon.  We thank Fred
   Templin for his review and contributions, and for sharing his
   experience with ISATAP.  Review and encouragement have been provided
   by many others and in particular Chris Chase, Thomas Clausen, Wouter
   Cloetens, Wojciech Dec, Bruno Decraene, Remi Despres, Alain Durand,
   Washam Fan, Martin Gysi, David Harrington, Jerry Huang, Peter McCann,
   Alexey Melnikov, Dave Thaler, Eric Voit, and David Ward.

15.  References

15.1.  Normative References

[RFC1918]      Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G.,
                  and E. Lear, "Address Allocation for Private
                  Internets", BCP 5, RFC 1918, February 1996.

[RFC2119]      Bradner, S., "Key words for use in RFCs to Indicate
                  Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2132]      Alexander, S. and R. Droms, "DHCP Options and BOOTP
                  Vendor Extensions", RFC 2132, March 1997.

[RFC2491]      Armitage, G., Schulter, P., Jork, M., and G. Harter,
                  "IPv6 over Non-Broadcast Multiple Access (NBMA)
                  networks", RFC 2491, January 1999.

Townsley & Troan             Standards Track                   [Page 16]
 
RFC 5969                           6rd                       August 2010

[RFC3056]      Carpenter, B. and K. Moore, "Connection of IPv6
                  Domains via IPv4 Clouds", RFC 3056, February 2001.

[RFC3168]      Ramakrishnan, K., Floyd, S., and D. Black, "The
                  Addition of Explicit Congestion Notification (ECN) to
                  IP", RFC 3168, September 2001.

[RFC4213]      Nordmark, E. and R. Gilligan, "Basic Transition
                  Mechanisms for IPv6 Hosts and Routers", RFC 4213,
                  October 2005.

[RFC4291]      Hinden, R. and S. Deering, "IP Version 6 Addressing
                  Architecture", RFC 4291, February 2006.

[RFC4861]      Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
                  "Neighbor Discovery for IP version 6 (IPv6)",
                  RFC 4861, September 2007.

15.2.  Informative References

[RFC2578]      McCloghrie, K., Ed., Perkins, D., Ed., and J.
                  Schoenwaelder, Ed., "Structure of Management
                  Information Version 2 (SMIv2)", STD 58, RFC 2578,
                  April 1999.

[RFC2983]      Black, D., "Differentiated Services and Tunnels",
                  RFC 2983, October 2000.

[RFC3068]      Huitema, C., "An Anycast Prefix for 6to4 Relay
                  Routers", RFC 3068, June 2001.

[RFC3484]      Draves, R., "Default Address Selection for Internet
                  Protocol version 6 (IPv6)", RFC 3484, February 2003.

[RFC3633]      Troan, O. and R. Droms, "IPv6 Prefix Options for
                  Dynamic Host Configuration Protocol (DHCP) version 6",
                  RFC 3633, December 2003.

[RFC3964]      Savola, P. and C. Patel, "Security Considerations for
                  6to4", RFC 3964, December 2004.

[RFC4632]      Fuller, V. and T. Li, "Classless Inter-domain Routing
                  (CIDR): The Internet Address Assignment and
                  Aggregation Plan", BCP 122, RFC 4632, August 2006.

[RFC5214]      Templin, F., Gleeson, T., and D. Thaler, "Intra-Site
                  Automatic Tunnel Addressing Protocol (ISATAP)",
                  RFC 5214, March 2008.

Townsley & Troan             Standards Track                   [Page 17]
 
RFC 5969                           6rd                       August 2010

[RFC5569]      Despres, R., "IPv6 Rapid Deployment on IPv4
                  Infrastructures (6rd)", RFC 5569, January 2010.

[RoutingLoop] Nakibly and Arov, "Routing Loop Attacks using IPv6
 Tunnels", August 2009, <http://www.usenix.org/event/
 woot09/tech/full_papers/nakibly.pdf>.

[TR069]        "TR-069, CPE WAN Management Protocol v1.1, Version:
                  Issue 1 Amendment 2", December 2007.

[V6OPS-LOOPS]  Nakibly, G. and F. Templin, "Routing Loop Attack using
                  IPv6 Automatic Tunnels: Problem Statement and Proposed
                  Mitigations", Work in Progress, May 2010.

Authors' Addresses

Mark Townsley
   Cisco
   Paris,
   France

EMail: mark@townsley.net

Ole Troan
   Cisco
   Bergen,
   Norway

EMail: ot@cisco.com

Townsley & Troan Standards Track [Page 18]
 
</pre>

IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) Protocol Specification

Internet Engineering Task Force (IETF) W. Townsley Request for Comments: 5969 ...

Transition From IPv4 to IPv6

What is IPv4 and IPv6 ?

C++ Internet Protocol and Socket Address Classes

How to add IPv6 over IPv4 support to your network behind a NAT router

Converting IPv4 addresses to IPv6 addresses

A Communication Mechanism between IPv4 and IPv6

Use of VLANs for IPv4-IPv6 Coexistence in Enterprise Networks

IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) Protocol Specification

ADV

Populars

Arsip Blog