What is tunneltrace?

                               TUNNELTRACE-RS v1.0<br />                               ===================<br /><br />What is tunneltrace?<br />--------------------<br /><br />Tunneltrace is a tool used for detecting IPv6 in IPv4 tunnels. More precisely,<br />Tunneltrace can run in 2 modes:<br />Mode 1:<br />  Given two IPv4 Addresses it checks if there is a tunnel between them. If there<br />is evidence of the presence of a tunnel, tunneltrace outputs a confidence<br />value, which provides a measure of the probability that the tunnel exists, and<br />tries to determine the IPv6 addresses of the endpoints. <br />Mode 2:<br />  Tunneltrace can also determine, given an IPv6 Address, the full Path from the<br />node where tunneltrace is launched to the given address. From the Path <br />determined tunneltrace identifies the Path MTU and all the tunnels inside the path, and for<br />each tunnel found it tries to find the IPv4 addresses of the endpoints and <br />outputs a confidence value. <br /><br />Techniques used<br />---------------<br /><br />Tunneltrace uses three techniques to detect tunnels:<br /><br />1) IPv4 spoofing<br />2) DNS lookups<br />3) Queries to the 6bone registry<br /><br />Each of the above techniques has a degree of confidence. The confidence value<br />output by tunneltrace is the sum of the confidence values of each technique<br />that succeeded.<br /><br /><br />Brief description of the techniques<br />-----------------------------------<br /><br />1. IPv4 spoofing<br /><br />These are the main techniques used by tunneltrace. By encapsulating an IPv6<br />packet in an IPv4 packet having the source address of one of the tunnel<br />endpoints, tunneltrace can trick the other endpoint into treating the packet as<br />if it had come from the tunnel.<br /><br />Tunneltrace uses four spoofing techniques:<br /><br />    a) Injected Ping<br />       Encapsulated IPv6 echo request to a pingable IPv6 interface. Used to<br />       determine if there is a tunnel.<br /><br />    b) Dying Packet<br />       Similar to the above, but injects packets with a Hop Count field of 1.<br />       Used to determine the IPv6 addresses of the tunnel endpoints.<br /><br />    c) Ping Pong Packet<br />       Similar to the above, but attempts to determine the address of one<br />       endpoint if the address of the other endpoint is known.<br /><br />    d) Fragmented Injection<br />       As Injected Ping but puts the IPv6 echo request message into three IPv4 fragments<br /><br />2. DNS Lookups<br /><br />Looks for AAAA records with the endpoint hostnames, if we are running tunneltrace in <br />mode 1.<br /><br />Looks for A records with the endpoint hostnames (retreived by a reverse-lookup),if we<br />are running tunneltrace in mode 2.<br /><br />3. Queries to the 6bone registry<br /><br />Looks for a corresponding entry in the 6bone registries. Tunneltrace requires<br />a copy of the 6bone registry file to be stored locally in /etc/6bone.db or <br />in the directory where tunneltrace is installed.<br />You may download this file from ftp://whois.6bone.net/6bone/6bone.db.gz<br /><br />A detailed description of the techniques used can be found in the papers<br />available at the URL:<br /><br />http://www.dia.uniroma3.it/~compunet/tunneldiscovery/tunneling-noms.pdf<br /><br />4) Path MTU Discovery<br /><br />Tunneltrace tries to send ICMPv6 packets with the MTU of the node where it is running<br />and using Hop Limit manipulation for determining the Path (Modifing the HL field). <br />If it receives a ICMPv6 message of Packet-Too-Big, from that point on it will send<br />packets with the MTU specified in the Packet-Too-Big messagge, until it doesn't <br />receive antoher packet too big messagge, and so on. <br /><br />5) Fragmented IPv6 in IPv4 Path MTU Discovery<br /><br />If Tunneltrace finds on its Path a Tunnel, it tryes to use the outern endpoint of it as Vantage Point <br />for Path MTU Discovery , by creating an IPv6 Packet of the MTU of the source node in IPv4 Fragments<br />of 68 bytes. So to be able to do Path MTU Discovery (and PATH TRACING with Hop Limit manipulation)<br />from the Vantage Point. This repeatably for every new Vantage Point that Tunneltrace finds further<br />on in the Path.<br /><br />How confidence values are calculated<br />------------------------------------<br /><br />The Confidence value output by tunneltrace is calculated using the following<br />criteria:<br /><br />Spoofing Techniques -><br />  Injected Ping success on 1 Endpoint only  : 5 Confidence Points  <br />  Injected Ping success of both Endpoints   : 7 Confidence Points<br />  Dying Packet success on each Endpoint     : 1 Confidence point<br />  Ping Pong Packet success on one Endpoint (if Dying Packet didn't work)<br />                                            : 1 Confidence point<br /><br />If Spoofing Techniques succeeded, then -><br />  6bone registries lookup success           : 1 Confidence points<br /><br /><br />If no Spoofing Technique succeeded, then -><br />  DNS lookups success                             : 1 Confidence points<br />  6bone registries lookup success           : 4 Confidence points<br /><br /><br />Compiling tunneltrace<br />---------------------<br /><br />To compile tunneltrace, run the build.sh script in the distribution.<br />Compilation requires the C++ development libraries to be installed.<br /><br />Tunneltrace is known to compile on Linux and FreeBSD, but should also compile<br />and run on other platforms such as Solaris.<br /><br />Tunneltrace runs on both littleEndian and bigEndian machines.<br /><br />Using tunneltrace<br />-----------------<br /><br />1. Prerequisites<br /><br />Due to the use of spoofing techniques that require raw sockets, you must be<br />root to run tunneltrace.<br /><br />Some of the techniques used by tunneltrace require a reference IPv6 address.<br />This address must be globally routed or, at a minimum, reachable from the<br />tunnel endpoints. The reference IPv6 address may be specified on the command<br />line using the -h parameter or in the file /etc/tunneltrace.ip.<br /><br />As stated previously, tunneltrace also requires a 6bone registry dump in the<br />file /etc/6bone.db or in the directory where tunneltrace is installed.<br /><br />You may run multiple istances of tunneltrace in parallel, since each one recognizes its<br />own packets.<br /><br />2. Usage<br /><br />Tunneltrace's syntax is the following :<br /><br />Mode 1:<br /><br />tunneltrace [ -h reference IPv6 ] [ -v ] <source IPv4> <dest IPv4><br />    Where <source IPv4> AND <dest IPv4>: IPv4 addresses or hostnames<br /><br />Mode 2:<br /><br />tunneltrace [ -h reference IPv6 ] <dest IPv6><br />    Where <dest IPv6>: IPv6 address or hostname<br /><br />Tunneltrace exits with an error if <source IPv4> or <dest IPv4> are not valid<br />IPv4 addresses or resolvable hostnames or if the reference IPv6 is not a valid<br />IPv6 address or <dest IPv6> is not a valid IPv6 address or resolvable hostname<br />or is not reachable.<br /><br />The -v option is used for generating Parametric OUTPUT (on one line) in order to <br />see the techniques that worked in detail<br /><br /><br />Output format<br />-------------<br /><br />The output format of tunneltrace is the following:<br /><br />Mode 1:<br /><br /># tunneltrace <source IPv4> <dest IPv4><br /><br />source_host(source_IPv4) -> dest_host(dest_IPv4)<br />source_IPv6 -> dest_IPv6 ; CONFIDENCE X/10<br /><br />Mode 2:<br /><br /># tunneltrace <dest IPv6><br /><br />1         host_1(IPv6_1)  MTU<br />2         host_2(IPv6_2)  MTU <br />source_host1(source_IPv4_1) -> dest_host2(dest_IPv4_2)<br />source_IPv6_1 -> dest_IPv6_2 ; CONFIDENCE X/10<br />3         host_3(IPv6_3)  MTU<br />.<br />.<br />8         host_dest(IPv6_dest)  MTU<br />If none of the techniques worked, tunneltrace will output a confidence value of<br />zero and one or both of the IPv6 addresses will be shown as "unknown".<br /><br /><br />Credits<br />-------<br /><br />Tunneltrace was developed as part of Davide De Micco's master thesis in<br />collaboration with the Computer Networks research group at Roma Tre University.<br /><br />Contributors are:<br /><br />Davide De Micco<br />Lorenzo Colitti<br />Giuseppe Di Battista<br />Emanuele Conti<br />Maurizio Patrignani

What is tunneltrace?

                               TUNNELTRACE-RS v1.0                                =================== What is tunneltrace? -----------------...

Read more »

Converting IPv4 addresses to IPv6 addresses

Converting IPv4 addresses to IPv6 addresses <br /> ------------------------------------------- <br /> Here's a cool tool for doing it in windows: <br /> <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> <br /> <br /> Here's the main ipv6 website: <br /> <br /> <a href="http://www.ipv6.org/" rel="nofollow">http://www.ipv6.org</a> <br /> <br /> There's a good read at Microsfoft on tcp/ip <br /> fundamentals and subnetting: <br /> <br /> <a href="http://www.microsoft.com/technet/itsolutions/network/evaluate/" rel="nofollow">http://www.microsoft.com/technet/itsolutions/network/evaluate/</a> <br /> technol/tcpipfund/tcpipfund_ch04.mspx#EEIAG <br /> <br /> Here are some OpenBSD related sites: <br /> <br /> <a href="http://www.inet6.dk/config/openbsd.html" rel="nofollow">http://www.inet6.dk/config/openbsd.html</a> <br /> <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> <br /> <br /> I'm sure there are scads more. Google is your friend! ;) <br /> <br /> Here are a few more, more general or linux: <br /> <br /> <a href="http://enterprisenetworkingplanet.com/netsp/article.php/3634596" rel="nofollow">http://enterprisenetworkingplanet.com/netsp/article.php/3634596</a> <br /> <a href="http://enterprisenetworkingplanet.com/netsp/article.php/3629546" rel="nofollow">http://enterprisenetworkingplanet.com/netsp/article.php/3629546</a> <br /> <a href="http://enterprisenetworkingplanet.com/netsp/article.php/3633211" rel="nofollow">http://enterprisenetworkingplanet.com/netsp/article.php/3633211</a> <br /> <br /> <br /> <br /> The examples below are pretty simple Class C <br /> network examples. I put several sequential <br /> addresses in order to show the progression <br /> in IPv6 notation. <br /> <br /> -------------------------------------------- <br /> IPV4 Address: 192.168.1.100 <br /> <br /> IPV6 Address: <br /> <br /> IPv6 Full Address <br /> 0000:0000:0000:0000:0000:0000:C0A8:0164 <br /> <br /> IPv6 Shorthand Adress: <br /> ::C0A8:0164 <br /> <br /> IPv6 & Dot Notation Full Address: <br /> 0000:0000:0000:0000:0000:0000:192.168.1.100 <br /> <br /> IPv6 & Dot Notation Shorthand Adress: <br /> 192.168.1.100 <br /> -------------------------------------------- <br /> <br /> <br /> -------------------------------------------- <br /> IPV4 Address: 192.168.1.101 <br /> <br /> IPV6 Address: <br /> <br /> IPv6 Full Address <br /> 0000:0000:0000:0000:0000:0000:C0A8:0165 <br /> <br /> IPv6 Shorthand Adress: <br /> ::C0A8:0165 <br /> <br /> IPv6 & Dot Notation Full Address: <br /> 0000:0000:0000:0000:0000:0000:192.168.1.101 <br /> <br /> IPv6 & Dot Notation Shorthand Adress: <br /> 192.168.1.101 <br /> -------------------------------------------- <br /> <br /> <br /> -------------------------------------------- <br /> IPV4 Address: 192.168.1.102 <br /> <br /> IPV6 Address: <br /> <br /> IPv6 Full Address <br /> 0000:0000:0000:0000:0000:0000:C0A8:0166 <br /> <br /> IPv6 Shorthand Adress: <br /> ::C0A8:0166 <br /> <br /> IPv6 & Dot Notation Full Address: <br /> 0000:0000:0000:0000:0000:0000:192.168.1.102 <br /> <br /> IPv6 & Dot Notation Shorthand Adress: <br /> 192.168.1.102 <br /> -------------------------------------------- <br /> <br /> <br /> -------------------------------------------- <br /> IPV4 Address: 192.168.1.103 <br /> <br /> IPV6 Address: <br /> <br /> IPv6 Full Address <br /> 0000:0000:0000:0000:0000:0000:C0A8:0167 <br /> <br /> IPv6 Shorthand Adress: <br /> ::C0A8:0167 <br /> <br /> IPv6 & Dot Notation Full Address: <br /> 0000:0000:0000:0000:0000:0000:192.168.1.103 <br /> <br /> IPv6 & Dot Notation Shorthand Adress: <br /> 192.168.1.103 <br /> -------------------------------------------- <br /> <br /> <br /> -------------------------------------------- <br /> IPV4 Address: 192.168.1.104 <br /> <br /> IPV6 Address: <br /> <br /> IPv6 Full Address <br /> 0000:0000:0000:0000:0000:0000:C0A8:0168 <br /> <br /> IPv6 Shorthand Adress: <br /> ::C0A8:0168 <br /> <br /> IPv6 & Dot Notation Full Address: <br /> 0000:0000:0000:0000:0000:0000:192.168.1.104 <br /> <br /> IPv6 & Dot Notation Shorthand Adress: <br /> 192.168.1.104 <br /> ----------------------

Converting IPv4 addresses to IPv6 addresses

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

Read more »

How To Setup IPv6

<pre>Introduction ************ IPv6 (Internet Protocol Version 6) is the successor, respectively the replacement, of the current version Internet Protocol, IPv4. The main problem using IPv4 is the growing shortage of IPv4 Addresses caused by the growing number of machines added to the internet. IPv6 fixes a number of problems in IPv4, such as the limited number of available IPv4 addresses. It also adds many improvements to IPv4 in areas such as routing and network autoconfiguration. IPv6 is expected to gradually replace IPv4, with the two coexisting for a number of years during a transition period. For this reason ePages supports IPv6 in version 6.0.6 and higher. Requirements ************ - ePages 6.0.6 or higher - License containing IPv6 address - Linux kernel 2.6 - Windows 2003 Server 32 Bit or Windows 2008 Server Prerequisites - Linux ===================== - Check if the network interface supports IPv6: ip -6 addr show If command returns nothing or an error occurs, ask your system administrator to add the IPv6 network interface (ip -6 addr add ...). - Check if the firewall allows IPv6 connections: PATH=$PATH:/usr/sbin:/sbin iptables -L If not, ask your system administrator to change the firewall settings. - If you use your own web server (not the web server that comes with ePages) and you want to use IPv6 for the web server, check the Listen directive in the configuration file (usually httpd.conf). Use 'Listen 80' (or other port), not 'Listen 0.0.0.0:80' (then only IPv4 is supported). Prerequisites - Windows ======================= - Enable IPv6 in Windows OS: Control Panel -> Network Connections -> Local Area Connection -> Properties -> Install... -> Protocol (Add) -> Microsoft TCP/IP version 6 - Check if the firewall allows IPv6 connections: Control Panel -> Windows Firewall - The IIS has to be unconnected or assigned to the correct IPv6 address if the IIS should run with IPv6: Administrative Tools -> IIS Manager -> Default Web Site -> IP Address (All Unassigned) IPv6 Activation *************** Activate IPv6 either in the setup process or after the setup process. Windows only supports IPv6 activation after setup, skip to the respective section. IPv6 Activation in Setup - Linux ================================ This section shows how to IPv6 during the setup. This works only for Linux, not for Windows. See section 'IPv6 Activation after Setup' if you want to enable IPv6 in ePages on Windows. Enable IPv6 by customizing your install.cnf file prior the installation process. You can skip the section "Post Installation" then. - The installation is defined in "install.cnf". - Append either ":ip6" to the hostname entry (the hostname has to be resolvable to an IPv6 address) or use an IPv6 address directly. - If IPv6 doesn't work on this machine the installation starts using IPv4. - If <hostname>:ip6 doesn't resolve to an IPv6 address the installation routine will try to get an IPv4 address for that hostname and use that one. - If that fails too the address ::1 will be used. IPv6 Activation After Setup =========================== Environment Variables --------------------- Windows: Set EPAGES_ENABLE_IPv6=1. The environment variable EPAGES_IPLIST must contain the IPv6 address or the hostname (whether you use IPv6 addresses or hostnames in Webinterface.conf) if EPAGES_IPBINDING is set. - Click the right mouse key on the "My computer" icon. - Choose "Properties". - On the tab "Advanced" click "Environment variables". - To create the variable click "New", then enter name (EPAGES_ENABLE_IPv6) and value (1) and save with "OK". - If the environment variable already exists, choose the variable from the list, click "Edit", enter the new value (1) and save with "OK". - Change EPAGES_IPLIST in the same way (if necessary). - Reboot the server to take effect of the new variable. Linux: Set EPAGES_ENABLE_IPv6=1. The environment variable LOCAL_IPS must contain the IPv6 address or the hostname (whether you use IPv6 addresses or hostnames in Webinterface.conf) if IP_BINDING is set. - Add line "export EPAGES_ENABLE_IPv6=1" to the configuration file "/etc/default/epages6". - Change EPAGES_IPLIST in "/etc/default/epages6" if necessary. If EPAGES_ENABLE_IPv6 is unset or 0, application server and request router only support IPv4. In this case, if application server or request router are configured to IPv6 in WebInterface.conf, errors will occur. Host Names and Addresses ------------------------ If a host name is resolved to both IPv4 and IPv6, then the IPv6 address is used if EPAGES_ENABLE_IPv6=1, otherwise the IPv4 address. In Windows, "localhost" is resolved to both 127.0.0.1 and ::1. In Linux, "localhost" is resolved to 127.0.0.1 and "ipv6-localhost" is resolved to ::1. If IP binding isn't used, a server can be connected with IPv6 and IPv4 clients if the server is set to IPv6 and has an IPv4 address too. WebInterface.conf ----------------- All IPv4 addresses can be replaced by IPv6 addresses or relevant host names. The hostname must be short (without ".") or the result of the command `hostname --fqdn`. In section "URLRewrite", line ExceptionHost, an IPv6 address has to be added in squared brackets, e.g.: [URLRewrite] ExceptionHost=shop.domain.ex [2001:4bd8:2:2:213:d3ff:fe62:f1f0] When using IP-Masks the part of the IP following the wildcard ("*") will be truncated and is considered as the beginning of the IP to be tested. IPv6 masks must be written in short form, i.e.: - Left-hand zeros have to be written - Zero blocks have to be shorten to :: In case of a mixed IPv4/IPv6 communication beside the IPv4 mask the IPv4 mask in IPv6 notation must also exist, e.g. ::ffff:172.20.24.*. If you use host names in WebInterface.conf, the corresponding IP entry or IP mask must also exit. Host masks as follows are not allowed: [*.epages.de] epages.conf ----------- IPv6 addresses can be entered in addition to IPv4 addresses and domain names. Sybase Configuration -------------------- Thy Sybase interfaces file (Linux: $SYBASE/interfaces; Windows: %SYBASE%\ini\sql.ini) may contain IPv4 addresses, IPv6 addresses or host names. For Windows, Sybase recommends to use IPv6 addresses instead of host names, see http://infocenter.sybase.com/help/index.jsp?topic=/com.sybase.dc38421_1500/html/ntconfig/X36043.htm. Hostnames will be resolved to IPv4 addresses on Windows, i.e. IPv4 is used if host names are entered in "sql.ini". If you want to support IPv4 and IPv6, you will need to have entries for both protocols, e.g.: DBServer master tcp ether revival.sybase.com 17100 query tcp ether revival.sybase.com 17100 master tcp ether revival.v6.sybase.com 17100 query tcp ether revival.v6.sybase.com 17100 The "*.res" files in $Sybase/ASE-15_0 can contain IPv6 addresses. Start ePages with IPv6 ********************** Windows hosts must be rebooted to take effect of the changes. After starting ePages, check if the services run with IPv6: Windows: netstat -a -n | perl -ne "s/ +/ /g; /TCP.*LISTENING/ && print" Linux: netstat -tulpn If the web server runs with IPv6, you can use the IPv6 address in square brackets in the URL, e.g.: http://[2001:4bd8:2:2:2e0:7dff:fe76:8613]:80/WebRoot/WebAdapterError.html </pre>

How To Setup IPv6

Introduction ************ IPv6 (Internet Protocol Version 6) is the successor, respectively the replacement, of the current version Interne...

Read more »

A Communication Mechanism between IPv4 and IPv6

<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...

Read more »

Pengenalan Internet Protokol versi 6 (IPv6)

<pre>Author: pangeran_biru Online @ www.echo.or.id :: http://ezine.echo.or.id === Pengenalan Internet Protokol versi 6 (IPv6) [primbon #1] === Assalamualaikum wr.wb Awalnya artikel ini saya tulis tentang implementasi IPv6 pada sistem operasi linux, tetapi setelah saya tulis kok kepanjangan kalo hanya dijadikan satu primbon oleh karena itu saya memutuskan menuliskannya kedalam 2 primbon (yaitu pengenalan IPv6 primbon #1, dan Implementasi IPv6 pada sistem operasi linux primbon #2). Dalam jaringan komputer dikenal adanya suatu protokol yang mengatur bagaimana suatu node berkomunikasi dengan node lainnya didalam jaringan, protokol tersebut berfungsi sebagai bahasa agar satu komputer dapat berkomunikasi satu dengan yang lainnya. protokol yang merupakan standar de facto dalam jaringan internet yaitu protokol TCP/IP, sehingga dengan adanya TCP/IP komputer yang dengan berbagai jenis hardware dan berbagai jenis sistem operasi (linux,Windows X, X BSD, de el el) tetap dapat berkomunikasi. Internet Protocol (IP) merupakan inti dari protokol TCP/IP, seluruh data yang berasal dari layer-layer diatasnya harus diolah oleh protokol ini agar sampai ketujuan.versi IP yang saat ini telah dipakai secara meluas di internet adalah Internet Protocol versi 4 (IPv4). perkembangan internet yang sangat pesat sekarang ini menyebabkan alokasi alamat (IP addres) IPv4 semakin berkurang, hal ini menyebabkan harga IP address legal sangat mahal (kecuali maok!!!heu...heu...).Untuk mengatasi kekurangan alokasi IP address maka IETF mendesain suatu IP baru yang disebut Internet Protocol versi 6 (IPv6). pada IPv6, panjang alamat terdiri dari 128 bit sedangkan IPv4 hanya 32 bit. sehingga IPv6 mampu menyediakan alamat sebanyak 2^128 [2 pangkat 128] atau 3X10^38 alamat, sedangkan IPv4 hanya mampu menyediakan alamat sebanyak 2^32 atau 4,5X10^10 alamat. oke, tadi cuma intro aja! sekarang kita lanjutkan ke yang lebih dalam lagi. kemon baybeh!!!!! sekarang saya akan menjelaskan perbedaan yang lainnya antara IPv4 dengan IPv6. A.Struktur pengalamatan #IPv4 pengalamatan IPv4 menggunakan 32 bit yang setiap bit dipisahkan dengan notasi titik. notasi pengalamatan IPv4 adalah sebagai berikut: XXXXXXXX.XXXXXXXX.XXXXXXXX.XXXXXXXX dimana setiap simbol X digantikan dengan kombinasi bit 0 dan 1.misalnya: 10000010.11001000.01000000.00000001 (dalam angka biner) cara penulisan lain agar mudah diinget adalah dengan bentuk 4 desimal yang dipisahkan dengan titik. misal untuk alamat dengan kombinasi biner seperti diatas dapat dituliskan sebagai berikut: 130.200.127.254 penulis sudah menganggap teman-teman semua dah bisa cara untuk mengkonversi dari bilangan biner ke desimal:). cos' kalo harus dijelasakan lagi nanti tambah ruwet nih artikel:p oke sekarang berlanjut ke struktur pengalamatan IPv6! #IPv6 Tidak seperti pada IPv4 yang menggunakan notasi alamat sejumlah 32 bit, IPv6 menggunakan 128 bit. dah tau khan kenapa jadi 128 bit? yup biar alokasinya bisa lebih banyak. oke sekarang kita liat notasi alamat IPv6 adalah sebagai berikut: X:X:X:X:X:X:X:X kalo dalam bentuk biner ditulis sebagai berikut: 1111111001111000:0010001101000100:1011111001000001:1011110011011010: 0100000101000101:0000000000000000:0000000000000000:0011101000000000 (dua blok diatas sebenarnya nyambung tapi agar tidak memakan tempat maka ditulis kebawah) itu notasi alamat IPv6 kalo dalam bentuk biner hal ini sengaja saya tulis bukan untuk membuat pusing yang baca tetapi untuk menunjukkan betapa panjangnya alamat IPv6. silahkan bandingkan dengan panjangnya IPv4. nah! agar lebih mudah diinget setiap simbol X digantikan dengan kombinasi 4 bilangan heksadesimal dipisahkan dengan simbol titik dua [:]. untuk contoh diatas dapat ditulis sbb: FE78:2344:BE43:BCDA:4145:0:0:3A lebih enak diliatnya khan?nah sistem pengalamatan IPv6 dapat disederhanakan jika terdapat berturut-turut beberapa angka "0". contohnya untuk notasi seperti diatas dapat ditulis: FE78:2344:BE43:BCDA:4145:0:0:3A -------> FE78:2344:BE43:BCDA:4145::3A contoh lagi: 8088:0:0:0:0:0:4508:4545 -------->8088::4508:4545 B.Sistem pengalamatan #IPv4 Sistem pengalamatan IPv4 dibagi menjadi 5 kelas, berdasarkan jumlah host yang dapat dialokasikan yaitu: Kelas A : range 1-126 Kelas B : range 128-191 kelas C : range 192-223 kelas D : range 224-247 kelas E : range 248-255 tapi yang lazim dipake hanya kelas A,B dan C sedangkan kelas D dipakai untuk keperluan alamat multicasting dan kelas E dipake untuk keperluan eksperimental. selain itu pada IPv4 dikenal istilah subnet mask yaitu angka biner 32 bit yang digunakan untuk membedakan network ID dan host ID, menunjukkan letak suatu host berada dalam satu jaringan atau lain jaringan.contohnya kaya gini: IP address: 164.10.2.1 dan 164.10.4.1 adalah berbeda jaringan jika menggunakan netmask 255.255.254.0, tetapi akan jika netmasknya diganti menjadi 255.255.240.0 maka kedua IP address diatas adalah berbeda jaringan. paham belom? kalo belom paham gini caranya: 164.10.2.1-------> 10100100.00001010.00000010.00000001 255.255.254.0----> 11111111.11111111.11111110.00000000 ____________________________________ XOR 10100100.00001010.00000010.00000000-->164.10.2.0 dan 164.10.4.1-------> 10100100.00001010.00001000.00000001 255.255.254.0----> 11111111.11111111.11111110.00000000 ____________________________________ XOR 10100100.00001010.00001000.00000000-->164.10.4.0 operasi XOR caranya seperti pertambahan waktu SD, cuman lebih mudah, gampangnya gini kalo angka "1" jumlahnya genap hasilnya "1" kalo jumlah "1" ganjil hasilnya "0" (1+1=1, 1+0=0) (heu...heu...). terlihat hasil operasi XOR dua IP address dengan netmask yang sama hasilnya beda berarti kedua IP address tersebut berbeda jaringan. untuk contoh berikutnya yang menggunakan netmask 255.255.240.0 silahkan coba sendiri. #IPv6 pada IPv6 tidak dikenal istilah pengkelasan, hanya IPv6 menyediakan 3 jenis pengalamatan yaitu: Unicast, Anycast dan Multicast. alamat unicast yaitu alamat yang menunjuk pada sebuah alamat antarmuka atau host, digunakan untuk komunikasi satu lawan satu. pada alamat unicast dibagi 3 jenis lagi yaitu: alamat link local, alamat site local dan alamat global. alamat link local adalah alamat yang digunakan di dalam satu link yaitu jaringan local yang saling tersambung dalam satu level. sedangkan alamat Site local setara dengan alamat privat, yang dipakai terbatas di dalam satu site sehingga terbatas penggunaannya hanya didalam satu site sehingga tidak dapat digunakan untuk mengirimkan alamat diluar site ini. alamat global adalah alamat yang dipakai misalnya untuk Internet Service Provider. alamat anycast adalah alamat yang menunjukkan beberapa interface (biasanya node yang berbeda). paket yang dikirimkan ke alamat ini akan dikirimkan ke salahsatu alamat antarmuka yang paling dekat dengan router. alamat anycast tidak mempunyai alokasi khusus, cos' jika beberapa node/interface diberikan prefix yang sama maka alamat tersebut sudah merupakan alamat anycast. alamat multicast adalah alamat yang menunjukkan beberapa interface (biasanya untuk node yang berbeda). Paket yang dikirimkan ke alamat ini maka akan dikirimkan ke semua interface yang ditunjukkan oleh alamat ini. alamat multicast ini didesain untuk menggantikan alamat broadcast pada IPv4 yang banyak mengkonsumsi bandwidth. Tabel alokasi alamat IPv6 __________________________________________________________________ |alokasi | binary prefix |contoh (16 bit pertama | |_______________|__________________________|_______________________| |Global unicast |001 | 2XXX ato 3XXX | |link local |1111 1110 10 | FE8X - FEBx | |site local |1111 1110 11 | FECx - FEFx | |Multicast |1111 1111 | FFxx | |_______________|__________________________|_______________________| selain alamat diatas tadi ada juga jenis pengalamatan lainnya diantaranya: #IPv4-compatible IPv6 address biasanya alamat ini digunakan untuk mekanisme transisi Tunelling format alamatnya kaya gini: 80 bits |16 | 32 bits | +-------------------+------+---------------------+ |0000...........0000| 0000 | IPv4 address | +-------------------+------+---------------------+ contohnya: = 0:0:0:0:0:0:192.168.30.1 = ::192.168.30.1 = ::C0A8:1E01 jadi 0:0:0:0:0:0:192.168.30.1=::c0AB:1E01 kok bisa dapat dari mane? gini caranya: buat dulu alamat 0:0:0:0:0:0:192.168.30.1 jadi biner ::11000000.10101000.00011110.00000001 kemudian kelompokkan menjadi masing 16 bit ::[1100.0000.1010.1000]:[0001.1110.0000.0001] diubah ke heksa desimal--->::C0A8:1E01 tanda "." (titik) didalam kurung untuk mempermudah konversi dari biner ke heksadesimal. sudah pahamkan? masih belum juga silahkan ulangi lagi dengan perlahan:p #IPv4-mapped IPv6 address biasanya digunakan untuk mekanisme transisi ISATAP. 80 bits |16 | 32 bits | +-------------------+------+---------------------+ |0000...........0000| FFFF | IPv4 address | +-------------------+------+---------------------+ contohnya: =::FFFF:192.168.1.2 #IPv6 over ethernet digunakan untuk stateless autoconfiguration (pemberian alamat IPv6 secara otomatis tanpa memerlukan server yang memberi alokasi IP address, mirip DHCP cuman tanpa server). contoh: 00:90:27:17:FC:0F /\ / \ FF FE maka alamatnya menjadi 00:90:27:FF:FE:17:FC:0F kemudian diblok pertama bit ketujuh diinvers 00:90:27:17:FC:0F | | \|/ 000000[0]0 bit yang dikurungi diinvers dari 0--->1 maka sekarang menjadi 02:90:27:FF:FE:17:FC:0F alamat tersebut adalah alamat IPv6 over ethernet. oke mungkin segitu dulu tulisan dari saya, sebagai dasar teori untuk IPv6 (ceile!!!!), sebenarnya masih banyak yang ingin saya tulis cuman nanti terlalu panjang nih artikel takut ga ada yang baca. (heu.....heu...) semoga tetap dalam semangat untuk berbagi!!!!! Wassalam kritik&saran silahkan kirim ke pan6eran_biru[at]yahoo.com Referensi:-TCP/IP standard,desain dan Implementasi, Onno W.purbo dkk -Teori dan Implementasi IPv6 Protokol Internet Masa depan, Riza Taufan -Interkoneksi IPv6 dengan menggunakan DSTM, Dody Setiawan -Implementasi dan Analisa Teredo untuk interkoneksi jaringan IPv6/IPv4 dengan jaringan IPv6 yang melalui IPv4 NAT (Network Address Translation), Wahidi Somad -Introduction & Deployment IPv6 Tutorial,Che Rohani Ishak dkk [###############################################################################################] thengkiyu tu :-aLL echo|staff, GreetZ to :-temen-temen seperjuangan: |blo`on|,gorila,dragon CCNA, mbah harjo,ksj, st3alth (adeku yang baik!), all dech!!! -barudak #sunda (belegug [salam blemoh!!!],Hendi, al-mubarak,all dech!) -special Kanggo: Neng Wiharyanti Purnama Dewi(kapan maen ke kost lagi?) -buat orang-orang yang pernah mencaci gw, mentertawakan gw, kalian adalah pemacu semangatku heu....heu... [###############################################################################################] </pre>

Pengenalan Internet Protokol versi 6 (IPv6)

Author: pangeran_biru Online @ www.echo.or.id :: http://ezine.echo.or.id === Pengenalan Internet Protokol versi 6 (IPv6) [primbon #1] === ...

Read more »

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

<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. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. 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: | n bits | o bits | m bits | 128-n-o-m bits | +---------------+--------------+-----------+------------------------+ | 6rd prefix | IPv4 address | subnet ID | interface ID | +---------------+--------------+-----------+------------------------+ |<--- 6rd delegated prefix --->| 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 ...

Read more »

A Model of IPv6 IPv4 Dual Stack Internet Access Service

<pre>Network Working Group Y. Shirasaki Request for Comments: 4241 S. Miyakawa Category: Informational T. Yamasaki NTT Communications A. Takenouchi NTT December 2005 A Model of IPv6/IPv4 Dual Stack Internet Access Service 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 (2005). IESG Note This RFC is not a candidate for any level of Internet Standard. The IETF disclaims any knowledge of the fitness of this RFC for any purpose and notes that the decision to publish is not based on IETF review apart from IESG review for conflict with IETF work. The RFC Editor has chosen to publish this document at its discretion. See RFC 3932 for more information. Abstract This memo is a digest of the user network interface specification of NTT Communications' dual stack ADSL access service, which provide a IPv6/IPv4 dual stack services to home users. In order to simplify user setup, these services have a mechanism to configure IPv6 specific parameters automatically. The memo focuses on two basic parameters: the prefix assigned to the user and the addresses of IPv6 DNS servers, and it specifies a way to deliver these parameters to Customer Premises Equipment (CPE) automatically. Shirasaki, et al. Informational [Page 1] RFC 4241 Dual Stack Access Service December 2005 1. Introduction This memo is a digest of the user network interface specification of NTT Communications' dual stack ADSL access service, which provide IPv6/IPv4 dual stack services to home users. In order to simplify user setup, these services have a mechanism to configure IPv6 specific parameters automatically. The memo focuses on two basic parameters: the prefix assigned to the user and the addresses of IPv6 DNS servers, and it specifies a way to deliver these parameters to Customer Premises Equipment (CPE) automatically. This memo covers two topics: an architecture for IPv6/IPv4 dual stack access service and an automatic configuration function for IPv6- specific parameters. The architecture is mainly targeted at a leased-line ADSL service for home users. It assumes that there is a Point-to-Point Protocol (PPP) logical link between Customer Premises Equipment (CPE) and Provider Edge (PE) equipment. In order to exclude factors that are specific to access lines, this architecture only specifies PPP and its upper layers. To satisfy [RFC3177], the prefix length that is delegated to the CPE is /48, but /64 is also a possible option. In this architecture, IPv6/IPv4 dual stack service is specified as follows. o IPv6 and IPv4 connectivities are provided over a single PPP logical link. o IPv6 connectivity is independent of IPv4 connectivity. IPV6CP and IPCP work independently over a single PPP logical link. Figure 1 shows an outline of the service architecture. NTT Communications has been providing a commercial service based on this architecture since the Summer 2002. | _____________ [HOST]-+ +-----------+ +----------+ / \ | | Customer | ADSL line | Provider | | ISP core and | +-+ Premises +---------------+ Edge |--| The internet | | | Equipment | to subscriber +-----+----+ \_____________/ [HOST]-+ +-----------+ | | | | +-----+------+ | +-+----------+ | AAA server | | | DNS server | +------------+ | +------------+ +-+--------------+ | NTP server etc.| Figure 1: Dual Stack Access Service Architecture +----------------+ Shirasaki, et al. Informational [Page 2] RFC 4241 Dual Stack Access Service December 2005 The automatic configuration function aims at simplification of user setup. Usually, users have to configure at least two IPv6-specific parameters: prefix(es) assigned to them [RFC3769] and IPv6 DNS servers' addresses. The function is composed of two sub-functions: o Delegation of prefix(es) to be used in the user site. o Notification of IPv6 DNS server addresses and/or other server addresses. Section 2 of this memo details the user/network interface. Section 3 describes an example connection sequence. 2. User/Network Interface This section describes details of the user/network interface specification. Only PPP over Ethernet (PPPoE) and its upper layers are mentioned; the other layers, such as Ethernet and lower layers, are out of scope. IPv4-related parameter configuration is also out of scope. 2.1. Below the IP Layer The service uses PPP connection and Challenge Handshake Authentication Protocol (CHAP) authentication to identify each CPE. The CPE and PE handle both the PPP Internet Protocol Control Protocol (IPCP) [RFC1332] and the Internet Protocol V6 Control Protocol (IPV6CP) [RFC2472] identically and simultaneously over a single PPP connection. This means either the CPE or the PE can open/close any Network Control Protocol (NCP) session at any time without any side- effect for the other. It is intended that users can choose among three services: IPv4 only, IPv6 only, and IPv4/IPv6 dual stack. A CPE connected to an ADSL line discovers a PE with the PPPoE mechanism [RFC2516]. Note that, because CPE and PE can negotiate only their interface identifiers with IPV6CP, PE and CPE can use only link-local-scope addresses before the prefix delegation mechanism described below is run. 2.2. IP Layer After IPV6CP negotiation, the CPE initiates a prefix delegation request. The PE chooses a global-scope prefix for the CPE with information from an Authentication, Authorization, and Accounting (AAA) server or local prefix pools, and it delegates the prefix to the CPE. Once the prefix is delegated, the prefix is subnetted and assigned to the local interfaces of the CPE. The CPE begins sending Shirasaki, et al. Informational [Page 3] RFC 4241 Dual Stack Access Service December 2005 router advertisements for the prefixes on each link. Eventually, hosts can acquire global-scope prefixes through conventional IPv6 stateless [RFC2462] or stateful auto-configuration mechanisms ([RFC3315], etc.) and begin to communicate using global-scope addresses. 2.3. Prefix Delegation The PE delegates prefixes to CPE using Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [RFC3315] with the prefix delegation options [RFC3633]. The sequence for prefix delegation is as follows: o The CPE requests prefix(es) from a PE by sending a DHCPv6 Solicit message that has a link-local source address negotiated by IPV6CP, mentioned in the previous section, and includes an IA_PD option. o An AAA server provides prefix(es) to the PE or the PE chooses prefix(es) from its local pool, and the PE returns an Advertise message that contains an IA_PD option and IA_PD Prefix options. The prefix-length in the IA_PD Prefix option is 48. IA_PD option and IA_PD Prefix options for the chosen prefix(es) back to the PE. o The PE confirms the prefix(es) in the Request message in a Reply message. If IPV6CP is terminated or restarted by any reason, CPE must initiate a Rebind/Reply message exchange as described in [RFC3633]. 2.4. Address Assignment The CPE assigns global-scope /64 prefixes, subnetted from the delegated prefix, to its downstream interfaces. When the delegated prefix has an infinite lifetime, the preferred and valid lifetimes of assigned /64 prefixes should be the default values in [RFC2461]. Because a link-local address is already assigned to the CPE's upstream interface, global-scope address assignment for that interface is optional. 2.5. Routing The CPE and PE use static routing between them, and no routing protocol traffic is necessary. Shirasaki, et al. Informational [Page 4] RFC 4241 Dual Stack Access Service December 2005 The CPE configures its PPPoE logical interface or the link-local address of PE as the IPv6 default gateway, automatically after the prefix delegation exchange. When the CPE receives packets that are destined for the addresses in the delegated /48 prefix, the CPE must not forward the packets to a PE. The CPE should return ICMPv6 Destination Unreachable message to a source address or silently discard the packets, when the original packet is destined for the unassigned prefix in the delegated prefix. (For example, the CPE should install a reject route or null interface as next hop for the delegated prefix.) 2.6. Obtaining Addresses of DNS Servers The service provides IPv6 recursive DNS servers in the ISP site. The PE notifies the global unicast addresses of these servers with the Domain Name Server option that is described in [RFC3646], in Advertise/Reply messages on the prefix delegation message exchange. Devices connected to user network may learn a recursive DNS server address with the mechanism described in [RFC3736]. The CPE may serve as a local DNS proxy server and include its address in the DNS server address list. This is easy to implement, because it is analogous to IPv4 SOHO router (192.168.0.1 is a DNS proxy server and a default router in most sites). 2.7. Miscellaneous Information The PE may notify other IPv6-enabled server addresses, such as Network Time Protocol servers [RFC4075], SIP servers [RFC3319], etc., in an Advertise/Reply message on the prefix delegation message exchange, if those are available. 2.8. Connectivity Monitoring ICMPv6 Echo Request will be sent to the user network for connectivity monitoring in the service. The CPE must return a single IPv6 Echo Reply packet when it receives an ICMPv6 Echo Request packet. The health-check packets are addressed to a subnet-router anycast address for the delegated prefix. The old document of APNIC IPv6 address assignment policy required that APNIC could ping the subnet anycast address to check address usage. Shirasaki, et al. Informational [Page 5] RFC 4241 Dual Stack Access Service December 2005 To achieve this requirement, for example, once the prefix 2001:db8:ffff::/48 is delegated, the CPE must reply to the ICMPv6 Echo Request destined for 2001:db8:ffff:: any time that IPV6CP and DHCPv6-PD are up for the upstream direction. Because some implementations couldn't reply when 2001:db8:ffff::/64 was assigned to its downstream physical interface and the interface was down, such an implementation should assign 2001:db8:ffff::/64 for the loopback interface, which is always up, and 2001:db8:ffff:1::/64, 2001:db8:ffff:2::/64, etc., to physical interfaces. 3. An Example of Connection Sequence CPE PE | | |----------PADI-------->| \ |<---------PADO---------| | PPPoE |----------PADR-------->| | Discovery Stage |<---------PADS---------| / | | |---Configure-Request-->| \ |<--Configure-Request---| | PPP Link Establishment Phase |<----Configure-Ack-----| | (LCP) |-----Configure-Ack---->| / | | |<------Challenge-------| \ |-------Response------->| | PPP Authentication Phase (CHAP) |<-------Success--------| / | | |---Configure-Request-->| \ |<--Configure-Request---| | |<----Configure-Nak-----| | PPP Network Layer Protocol Phase |<----Configure-Ack-----| | (IPCP) |---Configure-Request-->| | |<----Configure-Ack-----| / | | |---Configure-Request-->| \ |<--Configure-Request---| | PPP Network Layer Protocol Phase |<----Configure-Ack-----| | (IPV6CP) |-----Configure-Ack---->| / | | |--------Solicit------->| \ |<------Advertise-------| | DHCPv6 |--------Request------->| | |<--------Reply---------| / | | Figure 2: Example of Connection Sequence Shirasaki, et al. Informational [Page 6] RFC 4241 Dual Stack Access Service December 2005 Figure 2 is an example of a normal link-up sequence, from start of PPPoE to start of IPv6/IPv4 communications. IPv4 communication becomes available after IPCP negotiation. IPv6 communication with link-local scope addresses becomes possible after IPV6CP negotiation. IPv6 communication with global-scope addresses becomes possible after prefix delegation and conventional IPv6 address configuration mechanism. IPCP is independent of IPV6CP and prefix delegation. 4. Security Considerations In this architecture, the PE and CPE trust the point-to-point link between them; they trust that there is no man-in-the-middle and they trust PPPoE authentication. Because of this, DHCP authentication is not considered necessary and is not used. The service provides an always-on global-scope prefix for users. Each device connected to user network has global-scope addresses. Without any packet filters, devices might be accessible from outside the user network in that case. The CPE and each device involved in the service should have functionality to protect against unauthorized accesses, such as a stateful inspection packet filter. The relationship between CPE and devices connected to the user network for this problem should be considered in the future. 5. Acknowledgements Thanks are given for the input and review by Tatsuya Sato, Hideki Mouri, Koichiro Fujimoto, Hiroki Ishibashi, Ralph Droms, Ole Troan, Pekka Savola, and IPv6-ops-IAJapan members. 6. References 6.1. Normative References [RFC3177] IAB and IESG, "IAB/IESG Recommendations on IPv6 Address Allocations to Sites", RFC 3177, September 2001. [RFC1332] McGregor, G., "The PPP Internet Protocol Control Protocol (IPCP)", RFC 1332, May 1992. [RFC2472] Haskin, D. and E. Allen, "IP Version 6 over PPP", RFC 2472, December 1998. [RFC2516] Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D., and R. Wheeler, "A Method for Transmitting PPP Over Ethernet (PPPoE)", RFC 2516, February 1999. Shirasaki, et al. Informational [Page 7] RFC 4241 Dual Stack Access Service December 2005 [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998. [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC 3633, December 2003. RFC 3633, December 2003. [RFC2461] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. [RFC3646] Droms, R., "DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, December 2003. [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6", RFC 3736, April 2004. [RFC4075] Kalusivalingam, V., "Simple Network Time Protocol (SNTP) Configuration Option for DHCPv6", RFC 4075, May 2005. [RFC3319] Schulzrinne, H. and B. Volz, "Dynamic Host Configuration Protocol (DHCPv6) Options for Session Initiation Protocol (SIP) Servers", RFC 3319, July 2003. 6.2. Informative References [RFC3769] Miyakawa, S. and R. Droms, "Requirements for IPv6 Prefix Delegation", RFC 3769, June 2004. Shirasaki, et al. Informational [Page 8] RFC 4241 Dual Stack Access Service December 2005 Authors' Addresses Yasuhiro Shirasaki NTT Communications Corporation Tokyo Opera City Tower 21F 3-20-2 Nishi-Shinjuku, Shinjuku-ku Tokyo 163-1421, Japan EMail: yasuhiro@nttv6.jp Shin Miyakawa, Ph. D NTT Communications Corporation Tokyo Opera City Tower 21F 3-20-2 Nishi-Shinjuku, Shinjuku-ku Tokyo 163-1421, Japan EMail: miyakawa@nttv6.jp Toshiyuki Yamasaki NTT Communications Corporation 1-1-6 Uchisaiwaicho, Chiyoda-ku Tokyo 100-8019, Japan EMail: t.yamasaki@ntt.com Ayako Takenouchi NTT Cyber Solutions Laboratories, NTT Corporation 3-9-11 Midori-Cho, Musashino-Shi Tokyo 180-8585, Japan EMail: takenouchi.ayako@lab.ntt.co.jp Shirasaki, et al. Informational [Page 9] RFC 4241 Dual Stack Access Service December 2005 Full Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78 and at www.rfc-editor.org/copyright.html, 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 currently provided by the Internet Society.</pre>

A Model of IPv6 IPv4 Dual Stack Internet Access Service

Network Working Group Y. Shirasaki Request for Comments: 4241 S. Miy...

Read more »