IPV4 to IPV6: Easy Explanation Of IPv4

Converting IPv4 addresses to IPv6 addresses

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

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

Here's the main ipv6 website:

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

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

Here are some OpenBSD related sites:

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

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

Here are a few more, more general or linux:

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

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

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

IPV6 Address:

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

IPv6 Shorthand Adress:
 
::C0A8:0164

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

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

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

IPV6 Address:

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

IPv6 Shorthand Adress:
 
::C0A8:0165

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

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

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

IPV6 Address:

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

IPv6 Shorthand Adress:
 
::C0A8:0166

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

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

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

IPV6 Address:

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

IPv6 Shorthand Adress:
 
::C0A8:0167

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

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

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

IPV6 Address:

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

IPv6 Shorthand Adress:
 
::C0A8:0168

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

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

Converting IPv4 addresses to IPv6 addresses

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

Converting IPv4 addresses to IPv6 addresses ------------------------------------------- Here's a cool tool for doing it in windows: http://www.softpedia.com/get/Network-Tools/IP-Tools/IPConvert.shtml Here's the main ipv6 website: http://www.ipv6.org … Read more »

31May2014

Use of VLANs for IPv4-IPv6 Coexistence in Enterprise Networks

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

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

Use of VLANs for IPv4-IPv6 Coexistence in Enterprise Networks

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

Network Working Group T. Chown Request for Comments: 4554 University of Southampton Category: Informational June 2006 Use of VLANs for IPv4-IPv6… Read more »

31May2014

A Model of IPv6 IPv4 Dual Stack Internet Access Service

Tukiyooo 0 Dual Stack, Easy Explanation Of IPv4, Internet Protocol Version4 and IPv6, IPv4, IPv6, Service 18:47

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

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.

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

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

Tukiyooo 0 Dual Stack, Easy Explanation Of IPv4, Internet Protocol Version4 and IPv6, IPv4, IPv6, Service 18:47

Network Working Group Y. Shirasaki Request for Comments: 4241 S. Miyakawa Category: Informational T. Yamasaki … Read more »

31May2014

What is Internet Protocol version 4 ,There are currently two version of Internet Protocol (IP)

Tukiyooo 0 Easy Explanation Of IPv4 20:03

<div dir="ltr" style="text-align: left;" trbidi="on">What is Internet Protocol ? There are currently two version of Internet Protocol (IP): IPv4. It provides the backbone of the modern internet.and a new version called IPv6. IPv4 (Internet Protocol Version 4) is the fourth revision of the Internet Protocol (IP) used to to identify LAN device on a Network through an addressing system. The Internet Protocol is designed for use in interconnected systems of packet-switched computer communication networks<a data-ls-seen="1" href="http://www.ietf.org/rfc/rfc791.txt" target="_blank"></a>. IPv4 is the most widely deployed Internet protocol used to connect devices to the Internet. IPv4 uses a 32 bit address scheme allowing for a total of 2^32 addresses (just over 4 billion addresses).  With the growth of the Internet it is expected that the number of unused IPv4 addresses will eventually run out because every device -- including computers, smartphones and game consoles -- that connects to the Internet requires an address. <h3 style="text-align: center;"> Easy Explanation Of IPv4</h3>TCP does keep track of the order of packets and requires the destination computer to acknowledge that they are received. This is why one often sees the phrase TCP/IP. So why two protocols instead of just one? Arranging it like this allows for flexibility. If you are broadcasting a video to millions of people for example, you may not care if a packet or two get lost and don't want your server to deal with all of the acknowledgements. In this case, you can still use IP but don't need to use TCP. This flexibility is highly indicative of the design philosophy that went into the internet and is one of the reasons that it has been so successful. Breaking it down into small parts makes it easier to create solutions to new problems by using much of what already exists and adding just a few small parts. IPv4 is just one small but critical part of what makes the internet work. </div>

What is Internet Protocol version 4 ,There are currently two version of Internet Protocol (IP)

Tukiyooo 0 Easy Explanation Of IPv4 20:03

What is Internet Protocol ?There are currently two version of Internet Protocol (IP): IPv4. It provides the backbone of the modern internet.and a new version called IPv6. IPv4 (Internet Protocol Version 4) is the fourth revision of the Internet Pro… Read more »

04Nov2013

Converting IPv4 addresses to IPv6 addresses

Use of VLANs for IPv4-IPv6 Coexistence in Enterprise Networks

A Model of IPv6 IPv4 Dual Stack Internet Access Service

What is Internet Protocol version 4 ,There are currently two version of Internet Protocol (IP)

ADV

Populars

Arsip Blog