Embedded Systems September 2000 Vol13_10

Issue link:

Contents of this Issue


Page 107 of 229

as a unicast point-to-point link layer. IPv4 sites are assigned a unique IPv6 address prefix. Packets are then encapsulated using this prefix and transmitted over IPv4. No configured tunnels are required. 6to4 is typically implemented almost entirely in bor- der routers. 6over420 This RFC allows isolated IPv6 nodes, located on a physical link that has no directly connected IPv6 router, to run IPv6 by using an 1Pv4 multicast domain as their virtual local link. The 1Pv6 hosts do not require IPv4-com- patible addresses or configured tun- nels in this approach. Do your systems need to support botl1 IPv4 and 1Pv6, or just IPv6? That depends. If your systems will run in a private network, IPv6 alone is enough. The extra memory required by the IPv4 portion of the stack can be elimi- nated if your systems will never talk to IPv4-only applications. Even if your applications connect to the Internet, they can use tunnels to communicate with other 1Pv6-only applications. The dual-stack can be relegated to the routers connecting your private net- work to the Internet. In practice, the memory consumed by the IPv4 portion of the stack is rela- tively small, approximately 15KB for most implementations. Including it makes a nice insurance policy, espe- cially since the majority of the Internet will still be IPv4 for a while. With the dual-stack approach, you will be guar- anteed that your applications will work today and tomorrow, regardless of the mix of 1Pv4 and IPv6 machines on the network. Not if, but when The big question these days is not if IPv6 will be widely deployed, but when. IPv6 is already being rolled out in Japan and parts of Emope, where IPv4 addresses are increasingly diffi- cult to obtain. In North America, where IPv4 addresses remain more plentiful, IPv6 will deploy more slowly. Nevertheless, it's coming in the next few years. Will your systems be ready for the change? March 1999. 11. IEEE, "Protocol Independent Interfaces," IEEE Std. 1003.1g, 1997. esp Stephen Harpster is the engineering man- ager for IPv6 at Sun Microsystems Inc. He earned his BS in computer science at the Georgia Institute of Technology in 1982, and his MS in computer science/electrical engineering at Northwestern University in 1987. You can reach him via e-mail at stephen. harpster@sun. com. References All of the RFCs and drafts can be retrieved for free from the IETF at 1. RFC 1287, "Towards the Future Internet Architecture." D. Clark, L. Chapin, V. Cerf, R. Braden, and R. Hobby, December 1991 . 2. 1Pv6 and the Future of the Internet, Sun Microsystems, Inc., 1999. Available at papers/wp-ipv6/ipv6wp.pdf. 3. RFC 1883, "Internet Protocol, Version 6 (1Pv6) Specification," S. Deering and R. Hinden, December 1995. 4. RFC 1826, "IP Authentication Header," R. Atkinson, August 1995. 5. RFC 1827, "IP Encapsulating Security Payload (ESP)," R. Atkinson, August 1995. 6. RFC 2462, "1Pv6 Stateless Address Autoconfiguration," S. Thomson and T. Narten. December 1998. 7. Draft-ietf-ipngwg-addrconf-privacy-01, "Privacy Extensions for Stateless Address Autoconfiguration in 1Pv6," T. Narten and R. Draves, October 1999. 8. Draft-ietf-dhc-dhcpv6-15, "Dynamic Host Configuration Protocol for 1Pv6 (DHCPv6)," J. Bound, M. Carney, and C. Perkins, May 2000. 9. Draft-ietf-dhc-dhcpv6exts-12. "Extensions for the Dynamic Host Configuration Protocol for 1Pv6," J. Bound, M. Carney, and C. Perkins. May 2000. 10. RFC 2553, "Basic Socket Interface Extensions for 1Pv6," R. Gilligan, S. Thomson, J. Bound, and W. Stevens, 106 SEPTEMBER 2000 Embedded Systems Programming 12. Porting Networking Applications to the 1Pv6 APis, Sun Microsystems, Inc., October 1999. Available at porting_guide_ipv6.pdf. 13. RFC 1933, "Transition Mechanisms for 1Pv6 Hosts and Routers," R. Gilligan and E. Nordmark, April1996. 14. Draft-ietf-ngtrans-broker-02, "1Pv6 Tunnel Broker," A. Durand, P. Fasano, I. Guardini , and D. Lento. October 1999. 15. RFC 2765, "Stateless IP/ICMP Translation Algorithm (SliT)," E. Nordmark, February 2000. 16. RFC 2766, "Network Address Translation - Protocol Translation (NAT- PT.)," G. Tsirtsis and P. Srisuresh, February 2000. 17. Draft-ietf-ngtrans-tcpudp-relay-00, "An 1Pv6-to-1Pv4 Transport Relay Translator," J. Hagino and K. Yamamoto, January 2000. 18. Draft-ietf-ngtrans-dstm-01, "Dual Stack Transition Mechanism (DSTM)," J. Bound, L. Toutain, and H. Afifi, March 2000. 19. Draft-ietf-ngtrans-6to4-05.txt, "Connection of 1Pv6 Domains via 1Pv4 Clouds without Explicit Tunnels," B. Carpenter and K. Moore, May 2000. 20. RFC 2529, "Transmission of 1Pv6 over 1Pv4 Domains without Explicit Tunnels, " B. Carpenter and C. Jung, March 1999. Additional 1Pv6 resources This set of web pages provides good generic information on 1Pv6: playground.sun.comlpublipnglhtm/1 This document outlines the business and technical case for 1Pv6: case-for-ipv6-05. txt This is a geographic map that gives an idea of worldwide deployment: noc.ntua.grl-adamo/6bone/ The 1Pv6 Forum is a world-wide consor- tium of Internet vendors: www. ipv6forum. com/ These are slides from a good tutorial: www. viagenie. qc. cal en/ ipv6forum.pdf

Articles in this issue

Archives of this issue

view archives of EETimes - Embedded Systems September 2000 Vol13_10