A Model of IPv6 IPv4 Dual Stack Internet Access Service

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

A Model of IPv6 IPv4 Dual Stack Internet Access Service

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

Read more »

Konfigurasi IPV4 ke IPV6 tugas kuliah

Internet Protokol Versi 4  (IPv4)  dan  Internet Protokol Versi 6 (IPv6)<br /><br />I. <a href="http://ipv4-ipv6.blogspot.com/2013/11/konfigurasi-ipv4-ke-ipv6-tugas-kuliah.html">Internet Protokol Versi</a> 4 (IPv4)<br />IPv4 adalah sebuah jenis pengalamatan jaringan yang digunakan di dalam protokol<br />jaringan TCP/IP yang menggunakan protokol IP versi 4. IP versi ini memiliki keterbatasan<br />yakni hanya mampu mengalamati sebanyak 4 miliar host komputer di seluruh dunia.<br />Contoh alamat IPv4 adalah 192.168.0.3<br />Pada IPv4 ada 3 jenis Kelas, tergantung dari besarnya bagian host, yaitu kelas A (bagian<br />host sepanjang 24 bit , IP address dapat diberikan pada 16,7 juta host) , kelas B (bagian host<br />sepanjang 16 bit = 65534 host) dan kelas C (bagian host sepanjang 8 bit = 254 host ).<br />Administrator jaringan mengajukan permohonan jenis kelas berdasarkan skala jaringan yang<br />dikelolanya. Konsep kelas ini memiliki keuntungan yaitu : pengelolaan rute informasi tidak<br />memerlukan seluruh 32 bit tersebut, melainkan cukup hanya bagian jaringannya saja, sehingga<br />besar informasi rute yang disimpan di router, menjadi kecil. Setelah address jaringan diperoleh,<br />maka organisasi tersebut dapat secara bebas memberikan address bagian host pada masingmasing<br />hostnya.<br />Perbandingan IPv4 dan IPv6<br />Pemberian alamat dalam internet mengikuti format IP address (RFC 1166). Alamat ini<br />dinyatakan dengan 32 bit (bilangan 1 dan 0) yang dibagi atas 4 kelompok (setiap kelompok<br />terdiri dari 8 bit atau oktet) dan tiap kelompok dipisahkan oleh sebuah tanda titik. Untuk<br />memudahkan pembacaan, penulisan alamat dilakukan dengan angka desimal, misalnya<br />100.3.1.100 yang jika dinyatakan dalam binary menjadi<br />01100100.00000011.00000001.01100100. Dari 32 bit ini berarti banyaknya jumlah maksimum<br />alamat yang dapat dituliskan adalah 2 pangkat 32, atau 4.294.967.296 alamat. Format alamat ini<br />terdiri dari 2 bagian, netid dan hostid. Netid sendiri menyatakan alamat jaringan sedangkan<br />hostid menyatakan alamat lokal (host/router). Dari 32 bit ini, tidak boleh semuanya angka 0 atau<br />1 (0.0.0.0 digunakan untuk jaringan yang tidak dikenal dan 255.255.255.255 digunakan untuk<br />broadcast). Dalam penerapannya, alamat internet ini diklasifikasikan ke dalam kelas (A-E)..<br />Alasan klasifikasi ini antara lain :<br />· Memudahkan sistem pengelolaan dan pengaturan alamat-alamat.<br />· Memanfaatkan jumlah alamat yang ada secara optimum (tidak ada alamat yang<br />terlewat).<br />· Memudahkan pengorganisasian jaringan di seluruh dunia dengan membedakan jaringan<br />tersebut termasuk kategori besar, menengah, atau kecil.<br />· Membedakan antara alamat untuk jaringan dan alamat untuk host/router.<br />Pada tabel dibawah dijelaskan mengenai ketersediaan IPv4 berdasarkan data dari APNIC<br />sampai akhir tahun 1999 yang lalu dan total IP yang sudah dialokasikan ke tiap – tiap negara di<br />Asia Pasifik.<br /><br /><br />II.5 Internet Protokol Versi 6 (IPv6)<br />Transisi IPv4 ke IPv6 merupakan fenomena yang tidak dapat dielakan oleh semua<br />kalangan. Walaupun IPv4 tetap dapat digunakan, IPv6 memiliki versi design berbeda dan<br />memiliki kegunaan lebih dibanding IPv4. Disertai dengan tumbuhnya inovasi-inovasi perangkat<br />berteknologi, maka Negara-negara di dunia dituntut mampu bersaing atau setidaknya secara<br />bertahap mulai untuk mengimplementasikan IPv6. Menurut jurnal Internet Protocol,<br />diperkirakan tak sampai tahun 2011, jatah alamat IP yang masih belum digunakan saat ini akan<br />habis. Maka muncullah suatu metode peangalamatan baru yang dikenal dengan sebutan IPv6. Di<br />Indonesia, salah satu penyedia jasa Internet, Indosat Mega Media (Indosat M2), sejak 2004 telah<br />siap menyewakan jaringan IPv6 ini.<br />IPv6 merupakan metode pengalamatan IP yang perlahan-lahan mulai menggantikan IPv4.<br />IPv6 digunakan sebagai pengalamatan karena keterbatasan jumlah IP yang dimiliki oleh IPv4,<br />mengingat semakin bertambahnya perangkat berbasis IP saat ini. IPv6 atau Internet Protocol<br />version 6 adalah protokol Internet terbaru yang merupakan pengembangan lebih lanjut dari<br />protokol yang dipakai saat ini, IPv4 (Internet Protocol version 4). Pengalamatan IPv6<br />menggunakan 128-bit alamat yang jauh lebih banyak dibandingkan dengan pengalamatan 32-bit<br />milik IPv4. Dengan kapasitas alamat IP yang sangat besar pada IPv6, setiap perangkat yang<br />dapat terhubung ke Internet (komputer desktop, laptop, personal digital assistant, atau telepon<br />seluler GPRS/3G) bisa memiliki alamat IP yang tetap. Sehingga, cepat atau lambat setiap<br />perangkat elektronik yang ada dapat terhubung dengan Internet melalui alamat IP yang unik.<br />Protokol IPv6 ini memiliki beberapa fitur baru yang merupakan perbaikan dari IPv4,diantaranya<br />:<br />•Memiliki format header baru<br />Header pada IPv6 memiliki format baru yang didesain untuk menjaga agar overhead header<br />minimum, dengan menghilangkan field-field yang tidak diperlukan serta beberapa field opsional<br />Perbandingan IPv4 dan IPv6<br />yang ditempatkan setelah header IPv6. Header IPv6 sendiri besarnya adalah dua kali dari besar<br />header dari IPv4.<br />•Range alamat yang sangat besar<br />IPv6 memiliki 128-bit atau 16-byte untuk masing-masing alamat IP source dan destination.<br />Sehingga secara logika IPv6 dapat menampung sekitar 3.4 x 1038 kemungkinan kombinasi<br />alamat.<br />•Pengalamatan secara efisien dan hierarkis serta infrastruktur routing<br />Alamat global dari IPv6 yang digunakan pada porsi IPv6 di Internet, didesain untuk<br />menciptakan infrastruktur routing yang efisien, hierarkis, dan mudah dipahami oleh<br />pengembang.<br />• Konfigurasi pengalamatan secara stateless dan statefull<br />IPv6 mendukung konfigurasi pengalamatan secara statefull, seperti konfigurasi alamat<br />menggunakan server DHCP, atau secara stateless yang tanpa menggunakan server DHCP. Pada<br />konfigurasi kedua, host secara otomatis mengkonfigurasi dirinya sendiri dengan alamat IPv6<br />untuk link yang disebut dengan alamat link-lokal dan alamat yang diturunkan dari prefik yang<br />ditransmisikan oleh router local.<br />•Built-in security<br />Dukungan terhadap IPsec memberikan dukungan terhadap keamanan jaringan dan menawarkan<br />interoperabilitas antara implementasi IPv6 yang berbeda.<br />• Dukungan yang lebih baik dalam hal QoS<br />Pada header IPv6 terdapat trafik yang di identifikasi menggunakan field Flow Label, sehingga<br />dukungan QoS dapat tetap diimplementasikan meskipun payload paket terenkripsi melalui<br />IPsec.<br />• Protokol baru untuk interaksi node<br />Pada IPv6 terdapat Protokol Neighbor Discovery yang menggantikan Address Resolution<br />Protokol.<br />• EkstensibilitasIPv6 dapat dengan mudah ditambahkan fitur baru dengan menambahkan<br />header ekstensi setelah header IPv6. Ukuran dari header ekstensi IPv6 ini hanya terbatasi oleh<br />ukuran dari paket IPv6 itu sendiri.

Konfigurasi IPV4 ke IPV6 tugas kuliah

Internet Protokol Versi 4  (IPv4)  dan  Internet Protokol Versi 6 (IPv6) I. Internet Protokol Versi 4 (IPv4) IPv4 adalah sebuah jenis penga...

Read more »