IPv6 multicast address assignment with DHCPv6

<pre>Network Working Group J. Durand Internet-Draft GIP RENATER Expires: August 19, 2005 February 18, 2005 IPv6 multicast address assignment with DHCPv6 draft-jdurand-assign-addr-ipv6-multicast-dhcpv6-01 Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 19, 2005. Copyright Notice Copyright (C) The Internet Society (2005). All Rights Reserved. Abstract This document proposes a simple solution to solve IPv6 multicast address assignment problem using the DHCPv6 protocol. Durand Expires August 19, 2005 [Page 1] Internet-Draft IPv6 multicast address assignment with DHCPv6 February 2005 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 IPv6 multicast deployment status . . . . . . . . . . . . . 3 1.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.3 SSM: no solution needed . . . . . . . . . . . . . . . . . 3 1.4 Session announcement considerations . . . . . . . . . . . 4 2. State of the art for address assignment . . . . . . . . . . . 4 3. Assignment with DHCPv6 . . . . . . . . . . . . . . . . . . . . 4 3.1 New DHCPv6 options . . . . . . . . . . . . . . . . . . . . 4 3.1.1 IA_MA option for IPv6 Multicast Addresses . . . . . . 4 3.1.2 Scope Option for IPv6 multicast address . . . . . . . 6 3.2 Address timers . . . . . . . . . . . . . . . . . . . . . . 6 3.3 Assignment of a multicast prefix . . . . . . . . . . . . . 7 3.4 Client and server behavior . . . . . . . . . . . . . . . . 7 4. Group-ID consideration . . . . . . . . . . . . . . . . . . . . 8 5. Deployment scenarios - Case studies . . . . . . . . . . . . . 8 5.1 Scenario 1: Site deployment . . . . . . . . . . . . . . . 8 5.2 Scenario 2: Campus deployment . . . . . . . . . . . . . . 9 5.3 Scenario 3: ISP deployment . . . . . . . . . . . . . . . . 9 6. Security considerations . . . . . . . . . . . . . . . . . . . 9 7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 10 8. Discussions . . . . . . . . . . . . . . . . . . . . . . . . . 10 9. Changes from -00 . . . . . . . . . . . . . . . . . . . . . . . 10 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 10.1 Normative references . . . . . . . . . . . . . . . . . . . . 10 10.2 Informative references . . . . . . . . . . . . . . . . . . . 11 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 12 Intellectual Property and Copyright Statements . . . . . . . . 13 Durand Expires August 19, 2005 [Page 2] Internet-Draft IPv6 multicast address assignment with DHCPv6 February 2005 1. Introduction Embedded-RP [11] is the only available solution for IPv6 interdomain ASM. Embedded-RP requires an IPv6 multicast address assignment mechanism, as multicast addresses mapping to the RP cannot be guessed and manually built by users. This is depicted in section 2.1.2 of the IETF working group document draft-ietf-mboned-addrarch [13]. This document proposes a simple solution to assign IPv6 multicast addresses or prefixes using the DHCPv6 protocol [8]. 1.1 IPv6 multicast deployment status The document draft-jdurand-ipv6-multicast-ra [14] recalls the following: "The deployment of IPv6 multicast is expanding. Some networks have already put the service in production. Some gateways have been deployed, making it possible to have interoperability between IPv4 and IPv6 multicast. Some sites have even stopped IPv4 multicast, due to its complexity (due to NAT and MSDP for example) and only rely on IPv6 multicast, using the deployed gateways for interoperability with IPv4. As of this writing, most sessions are created manually from unicast-prefix based address space [6], or use SDR to form a semi-random address. Nevertheless these addresses cannot fit with embedded-RP [11] which is the only existing solution for IPv6 interdomain ASM. Some people argue that SSM solves the problem but there is nowadays a demand from customers to be capable to have multicast sessions (both IPv4 and IPv6) with multiple sources (e.g., conferencing) and it is not clear how to achieve this with SSM. While "multiple-source SSM" could potentially be done with the aid of SIP or RTP, this does not exist yet, and a simple solution for ASM is needed." 1.2 Terminology 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 [1]. 1.3 SSM: no solution needed In the SSM model, as the channel is defined by the tuple (source address , group address), a collision can only occur if a host would like to be a sender for 2 different groups having the same address. Durand Expires August 19, 2005 [Page 3] Internet-Draft IPv6 multicast address assignment with DHCPv6 February 2005 Therefore, it is sufficient for a sender to choose different addresses for different channels, this is a decision local to the host. This document only considers the ASM model which is a bit more complex. 1.4 Session announcement considerations This document does not address the session announcement problem. It only answers the question of large scale address assignemnt of IPv6 multicast addresses. Announcement of the sessions can still be done using web pages, emails, directories, SAP, etc. 2. State of the art for address assignment MADCAP [2] solves, or could solve, the multicast address assignment problem for both IPv4 and IPv6. However, MADCAP is a fork of DHCP, it has only a couple of implementations which have not been widely deployed. We assume that a mechanism that would be a simple extension to a more widely available mechanism (DHCPv6) could be more deployed. This proposal and draft-jdurand-ipv6-multicast-ra [14] simplify the assignment architecture since the unicast and multicast address assignment mechanisms become the same. We consider at this stage only IPv6 multicast since most of the key elements used are already defined, and interaction with IPv4 multicast is ensured. If felt needed by the community, this proposal could be extended to IPv4. 3. Assignment with DHCPv6 3.1 New DHCPv6 options This section introduces new options for IPv6 multicast address assignment with DHCPv6. 3.1.1 IA_MA option for IPv6 Multicast Addresses RFC 3315 [8] defines the following options for Identity Associations (IA): o IA_NA option for Non temporary Addresses o IA_TA option for Temporary Addresses This document introduces a third option: the IA_MA option for IPv6 Multicast Addresses. This option is used to carry an IA_MA, the parameters associated with the IA_MA, and the addresses associated with the IA_MA. The format of the IA_MA option is: Durand Expires August 19, 2005 [Page 4] Internet-Draft IPv6 multicast address assignment with DHCPv6 February 2005 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-code | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IAID (4octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . IA_MA-options . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ option-code: OPTION_IA_MA (TBD) option-len: 4 + length of IA_MA-options field IAID: The unique identifier for this IA_MA; the IAID must be unique among the identifiers for all of this client's IA_MAs. The number space for IA_MA IAIDs is separate from the number space for IA_NA and IA_TA IAIDs IA_MA-Options: Options associated with this IA_MA The IA_MA-options field encapsulates those options that are specific to this IA_MA. For example, all of the IA Address Options carrying the multicast addresses associated with this IA_MA are in the IA_MA-options field. Each IA_MA carries one "set" of multicast addresses; that is, at most one address per session created by the client requiring an address. An IA_MA option may only appear in the options area of a DHCP message. A DHCP message may contain multiple IA_MA options. The status of any operations involving this IA_MA is indicated in a Status Code option in the IA_MA-options field. Note that an IA has no explicit "lifetime" or "lease length" of its own. When the valid lifetimes of all of the addresses in an IA_MA have expired, the IA can be considered as having expired. An IA_MA option does not include values for T1 and T2 (see RFC 3315 [8]). A client MAY request that the lifetimes of multicast addresses be extended by including the addresses in a IA_MA option sent in a Renew or Rebind message to a server. For example, a client would request an extension on the lifetime of a multicast address to allow an application to continue a multicast session. The client obtains new multicast addresses by sending an IA_MA option Durand Expires August 19, 2005 [Page 5] Internet-Draft IPv6 multicast address assignment with DHCPv6 February 2005 with a new IAID to a server. The server will generate new multicast addresses and return them to the client. In case the clients needs to extend the multicast session, it sends a Renew message to the server with the IA_MA and addresses in parameters. 3.1.2 Scope Option for IPv6 multicast address The scope option for IPv6 multicast addresses is used by the clients to request multicast addresses with a certain scope. It is included in the IA address option IAaddr-options field defined in section 22.5 of RFC 3315 [8]. A user can attach more than one scope option for IPv6 multicast address to an IA address option if the client does not know exactely the scope it wants to request but has a set of adequate scope values. 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_SCOPE | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | scope | res | +-+-+-+-+-------+ option-code: OPTION_SCOPE (TBD) option-len: 1 scope: The scope value for the requested IPv6 multicast address, according to values defined in RFC 3513 [9] res: This field is reserved for future use. The 4 bits of this field MUST be set to 0, and MUST be ignored on receipt 3.2 Address timers NOTE: There have been some discussions about using some options for the timers. This is let to next releases of the document as this release really focuses on why an assignment based on DHCPv6 has an interest. The IA address option defined in RFC 3315 [8] contains the following 32 bits fields: o preferred-lifetime: The preferred lifetime for the IPv6 address in the option, expressed in units of seconds o valid-lifetime: The valid lifetime for the IPv6 address in the Durand Expires August 19, 2005 [Page 6] Internet-Draft IPv6 multicast address assignment with DHCPv6 February 2005 option, expressed in units of seconds We suggest to use these fields, usually defined for unicast addresses, for IPv6 multicast addresses, with the definition written above. The maximum value for these lifetimes is 2^32 seconds or 49710 days equivalent to 136 years. Therefore a host that wants to be assigned an address for a 2 days session occuring in 30 days can request an address with a preferred lifetime value of 32 days. According to the IPv6 multicast addressing space available, servers should allow this type of requests, or at least should permit a certain number of long-term assignment per host. The address is directly assigned by the DHCP server when the request is received. We suggest here not using the parameters minDesiredStartTime and maxDesiredStartTime specified in RFC 2771 [3] which bring too much complexity for the assignment and don't really make sense for IPv6 where many addresses are available. 3.3 Assignment of a multicast prefix The assignment of a multicast prefix can be needed in the following scenarios: o An ISP needs to assign a block of IPv6 multicast address to an enterprise, assigning IPv6 multicast addresses to its hosts. This scenario will most likely occur when DHCPv6 prefix delegation [10] is already used to assign unicast prefixes to the enterprise. o Also it is most likely that the multicast applications will not support at the beginning the API to request for an IPv6 multicast address via DHCPv6. Then, on startup, or when connected to a new network, a host could ask for an IPv6 multicast prefix. Applications could then choose locally multicast addresses in the prefix assigned to the host. To fulfill this need, the prefix delegation mechanism described in RFC 3633 [10] is needed also for multicast prefixes. The actual specifications of the IPv6 prefix Options for DHCPv6 do not need to be changed to support multicast prefix delegations. The only thing to keep in mind is that multicast prefix delegation can also occur between a router and a host to fulfill the second requirement mentioned above. 3.4 Client and server behavior The procedures to request an IPv6 multicast address is more or less the same than the ones described in RFC 3315 [8] to request a Durand Expires August 19, 2005 [Page 7] Internet-Draft IPv6 multicast address assignment with DHCPv6 February 2005 temporary IPv6 address. The differences are following: o The client uses IA-type IA_MA described above to ask for IPv6 multicast addresses. o The client SHOULD use the Scope Option in solicit and request messages to tell the server the scope wanted for the IPv6 multicast address requested. It can include more than one Scope Option for IPv6 multicast address per addresses requested in case the client does not know exactly the scope it wants to request but has a set of adequate scope values. o The client SHOULD specify the lifetimes for every address it wants to be assigned in solicit, request, renew and rebind messages. o The server MUST assign addresses only if it can assign an address matching one of the scope requested. In case the server can't assign an address with the requested scopes, it must include the Status Code Option NoAddrsAvail in the advertise and reply messages and should include a status message with the scopes that can be assigned by the server and their description. o If no scope option is specified by the client, the server can assign a multicast address with any scope. It can be a default scope value configured by the DHCP server administrator. 4. Group-ID consideration RFC 3307 [7] defines guidelines for the choice of IPv6 multicast group identifier (the last 32 bits of the IPv6 multicast address). It specifies that for dynamic IPv6 multicast address allocation, the group-ID MUST be in the range 0x80000000 to 0xFFFFFFF. 5. Deployment scenarios - Case studies This section gives examples of DHCPv6 deployments for IPv6 multicast address assignment. 5.1 Scenario 1: Site deployment Consider a site having configured a DHCPv6 server and having one RP for a site-local scope (scope 5). In this simple scenario, the DHCPv6 server can assign the complete set of addresses with a site-local scope. We have the same scenario if the site configures one RP for global scope with embedded-RP technology. The DHCPv6 server of the site can Durand Expires August 19, 2005 [Page 8] Internet-Draft IPv6 multicast address assignment with DHCPv6 February 2005 assign the complete set of addresses derived from the RP's address (see Embedded-RP [11]). 5.2 Scenario 2: Campus deployment Consider a campus having configured one DHCPv6 server for the entire site, and having several labs (in different subnets) having each a multicast scope for their own usage. Every lab might have for example a scope admin-local (scope 4), and the campus may have the scope site-local (scope 5). The problem of the DHCPv6 server is to assign appropriate addresses to each of the labs. The server can retrieve information about the location of the client according to the explanation given in section 11 of RFC 3315 [8]. The server can determine this way in which lab the client is and assign adequate addresses. This way a server can assign the same address twice to different clients in different labs. 5.3 Scenario 3: ISP deployment Consider an ISP providing a global RP service to its customers. The ISP decided to use embedded-RP technology for this RP. Every customers having configured a DHCPv6 server would like to assign IPv6 multicast addresses based on the RP of their ISP. The problem is to avoid overlap between addresses assigned by every DHCPv6 servers. In this scenario, the ISP having configured an RP would allocate a range of IPv6 multicast addresses based on its RP to every customer having subscribed for the service (as explained in section 5.2 of Embedded-RP [11]). This allocation could be typically hand-off allocation, as it is done between ISP and big customers (not end-users at home) for unicast or could be done with DHCPv6 prefix delegation as explained in this document. This way, every DHCPv6 server is then configured with a different multicast address range, all matching the same RP. This means that ISPs need to allocate IPv6 multicast addresses to their customers, as they do today for IPv6 unicast. Address allocation architectures are exactly the same. Nevertheless, we can note that any customer could deploy its own embedded-RP rather than using the one of its ISP, which simplifies this scenario. 6. Security considerations The security considerations related to the DHCPv6 protocol are discussed in the security considerations section of [8]. Durand Expires August 19, 2005 [Page 9] Internet-Draft IPv6 multicast address assignment with DHCPv6 February 2005 7. Acknowledgement The author would like to thank Bernard Tuy, Stig Venaas, Christian Strauf, Pekka Savola and Dave Thaler for their good contributions to this memo. The author would also like to thank Ralph Droms who took time to consider the IPv6 multicast assignment problem and introduced the concept of the identity association for IPv6 multicast addresses. The author would also like to thank all the people having worked on the 6NET Deliverable 3.4.3 [12], which was the initial document that raised the complete problematic of IPv6 multicast address assignment. Pekka Savola, Dave Thaler, Stig Venaas and Bernard Tuy have contributed to better state the problem and mention why the proposal is of interest. 8. Discussions Here are the current discussions and questions about this document: o Timers could be specified with a new DHCPv6 option rather than overloading the timers of the address o If the server cannot assign addresses for the required scopes, it could assign an address in any other scope it is configured for. 9. Changes from -00 o Clarification of the need for the proposal o The multicast address assignment state of the art is now let to ID.draft-ietf-mboned-addrarch [13]. o IPv6 multicast prefix delegation is now supported by this mechanism, from comments received in IETF 60th. 10. References 10.1 Normative references [1] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [2] S. Hanna, B. Patel and M. Shah, "Multicast Address Dynamic Client Allocation Protocol (MADCAP)", RFC 2970, December 1999. [3] R. Finlayson, "An Abstract API for Multicast Address Durand Expires August 19, 2005 [Page 10] Internet-Draft IPv6 multicast address assignment with DHCPv6 February 2005 Allocation", RFC 2771, February 2000. [4] M. Handley, C. Perkins and E. Whelan, "Session Announcement Protocol (SAP)", RFC 2974, October 2000. [5] D. Meyer and P. Lothberg, "GLOP Addressing in 233/8", RFC 3180, September 2001. [6] B. Haberman and D. Thaler, "Unicast-Prefix-based IPv6 Multicast Addresses", RFC 3306, August 2002. [7] B. Haberman, "Allocation Guidelines for IPv6 Multicast Addresses", RFC 3307, August 2002. [8] R. Droms, J. Bound, B. Volz, T. Lemon, C. Perkins and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. [9] R. Hinden and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003. [10] O. Troan, R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC 3633, December 2003. [11] P. Savola and B. Haberman, "Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address", November 2004. 10.2 Informative references [12] 6NET project partners, "6NET D3.4.3 - IPv6 multicast address allocation study", May 2003. [13] P. Savola, "Overview of the Internet Multicast Addressing Architecture", November 2004. [14] J. Durand and P. Savola, "RA for IPv6 multicast prefixes", February 2005. Durand Expires August 19, 2005 [Page 11] Internet-Draft IPv6 multicast address assignment with DHCPv6 February 2005 Author's Address Jerome Durand GIP RENATER 151 Bd de l'Hopital Paris 75013 France Phone: +33 1 53 94 20 30 EMail: Jerome.Durand@renater.fr Durand Expires August 19, 2005 [Page 12] Internet-Draft IPv6 multicast address assignment with DHCPv6 February 2005 Intellectual Property Statement 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 IETF's procedures with respect to rights in IETF 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. Disclaimer of Validity 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. Copyright Statement Copyright (C) The Internet Society (2005). 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society.</pre>

IPv6 multicast address assignment with DHCPv6

Network Working Group J. Durand Internet-Draft GIP RE...

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 »

Use of VLANs for IPv4-IPv6 Coexistence in Enterprise Networks

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

Use of VLANs for IPv4-IPv6 Coexistence in Enterprise Networks

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

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 »