Search

ZigBee is a standard which is considered to be suitable for wireless sensor networks. In ZigBee, a device is said to join a network if it can obtain a network address from a parent device. Devices calculate addresses for their child devices by a distributed address assignment scheme. This assignment is easy to implement, but it restricts the number of children of a device and the depth of the network. We observe that if one uses the random formation policy specified in ZigBee, the utilization of the address pool will be very low. Those devices that can not receive network addresses will be isolated from the network and become orphan nodes. In this paper, we model the orphan problem by two subproblems: the bounded-degree-and-depth tree formation (BDDTF) problem and the end-device maximum matching (EDMM) problem. We then present solutions to these problems. The results can be applied to network formation in ZigBee networks.

In general IP networks, addresses can be assigned to hosts manually by a network administrator or automatically by a DHCP server. Mobile ad-hoc network (MANET), which is a self-configuring network, is the union of mobile hosts that form an arbitrary topology. Most research related to the MANET assumes that host's IP address is configured, prior to the node joining the MANET. However, it is impossible that a network administrator or DHCP server configures host IP addresses in MANETs because there is no infra-structure. For this reason, a dynamic address management protocol is essential in MANETs. Thus, this paper proposes a novel self-configuring address management protocol, referred to as DAP (distributed address pool), in which IP addresses can be dynamically allocated to a newly-joined host in MANETs with no network infra-structure. In DAP, every host in a MANET has a unique IP address pool (a set of unused addresses that will be used for new joined hosts in MANETs) and address assignments are performed locally in the host. The advantage of this method is that it does not generate any broadcasting messages and, in turn, address allocation time can be significantly reduced. From our simulations, DAP showed a superior performance to a random address allocation scheme (RADA) in terms of both address allocation time and message exchange overhead.

As migration to IPv6 in US, driven by the exhaustion of the IPv4 global address pool or by US DoD (Department of Defense) mandate etc, is picking up its momentum within enterprise networks, the Service Providers (SP) are also investigating multiple options to support customer IPv6 sites through a gradual upgrade to IPv6. These options include dual-stack, tunneling and translation. More importantly, SPs are considering this migration to IPv6 as an opportunity to develop and design their next generation networks and services. These novel services may not necessarily depend on IPv6 technology (could as well be done with IPv4) but IPv6 provides an opportunity to evaluate new design and service ideas. This paper talks about such potential opportunities, some entirely new while others being solutions to problematic aspects of SP’s existing IPv4 network and yet others are an attempt to define new services based on IPv6 technology specifics.

Over the paste decade, IPv6 community?s efforts to promote the next generation of the IP protocol revolved around generating business models that would justify the migration costs. The context, a depleting global address pool, and the target, global services, missed on one interesting opportunity for IPv6. Larger IP Service Provider and Enterprise networks are running out of IPv4 resources to manage their devices. Alleviating this problem with the help of IPv6 would be more valuable to them in the immediate future than providing user services. This paper reviews the current interest in leveraging IPv6 for management and it analyzes few possible protocol extensions that would enable its use in this role to a larger extent. While the paper discusses some of the challenges faced by these deployment proposals, it contends that this could be a reasonable and practical first step in the early adoption of IPv6 in large networks.

With the rapid development and enhancement on Internet technology, the shortage of traditional IPv4 address has been gradually recognized. It is estimated that the IPv4 address pool will be run out during 2022-2028. In order not to impede the diffusion and development of Internet technology, the next generation Internet protocol has been proposed. As we know, the invention of the new IP protocol standard provides a solution to solve the problem of insufficient IP address. However, it is a costly and enduring process to migrate from the IPv4 to IPv6. By analyzing worldwide IPv6 related products, we report Taiwan's strength and challenges in developing IPv6 and propose future development for industry and policy making.

This paper proposes an extension scheme to support effectively real-time services in Mobile IPv6. The proposed scheme could very simplify the handover procedure by using the proposed reserved addresses scheme and layer 2 triggers so that it could considerably reduce handover latency in Mobile IPv6. The performance analysis shows that the handover latency in the proposed scheme could be reduced by a minimum of 1 second, maximum of above 3 second as compared to that of basic Mobile IPv6. Accordingly the proposed scheme could be considered as a strong candidate to support real-time services like VoIP in future network based on Mobile IPv6

Virtual private networks (VPNs) are commonly used to connect branch offices, mobile users, and business partners. The two common types of VPNs are site-to-site and remote access. The PIX firewall supports VPNs using IPsec. The most robust tunneling solution for IP networks is the IPsec suite of protocols. It was developed by IETF as part of IPv6. IPsec operates at Layer 3 of the OSI model, which means that it can protect communications from the network layer (IP) and up. IPsec specifies encryption and authentication algorithms, AH and ESP protocols are used for tunneling itself and the IKE/ISAKMP key management protocol. IPsec's main goals are data confidentiality, data integrity, data origin authentication, and anti-replay service. When a site-to-site IPsec tunnel is configured on a PIX firewall, one of two main methods of IICE authentication is used: preshared keys or digital certificates. The former is simpler to set up, but lacks scalability offered by the digital certificate solution. In the second type of VPN, remote clients connect to a gateway. The PIX supports IPsec, which works with Layer 3 tunnels. Cisco has its own software VPN client that provides full IPsec features when working with the PIX firewaU. It can perform IKE authentication with both preshared keys and digital certificates. The PIX uses two extensions to IKE to provide VPN clients with an internal IP address (address pool configuration) and perform extra authentication of clients during IKE negotiation using Extended Authentication (xauth).

This chapter deals with the dynamic assignment of IP addresses using the BOOTP and DHCP protocols. The reasons for, and the history behind, the development of these protocols is covered and learned in detail how they work. Both the protocols make use of a specially defined packet that uses a UDP datagram addressed to specific UDP ports, namely port 68 (BOOTP client) and port 67 (BOOTP server). The chapter explains how DHCP was designed to be an extension of BOOTP. It uses the same packet definition, same UDP ports, and the same BOOTREQUEST and BOOTREPLY messages, but it relies very heavily on the vendor extensions field, which is now called simply the options field. DHCP provides more options in terms of address assignments. It can hand out addresses from a BOOTP-like database file, or it can hand addresses out on a first-come, first-served basis from an established address pool, sometimes called a scope. DHCP configuration can be much simpler than BOOTP, since it is not necessary to match each client manually to an individual address assignment. It also explains why unlike BOOTP, DHCP can be configured to assign addresses for a finite time period, called a lease. DHCP clients are required to renew their lease on an address periodically, or it will be reclaimed by the server once the lease period expires, and will be reassigned to a new client. Finally it is described how, to accommodate client requests that cross subnet boundaries, the BOOTP specification includes the definition of a BOOTP relay agent, which listens for client requests on its local subnet, and forwards them as unicast messages across router boundaries to the server. It performs the reverse function for the server as well. Both BOOTP and DHCP can make use of relay agents.

Before a session in a synchronous, collaborative environment can really start, various actions have to be performed: users have to be informed about planned sessions, network access paths between session participants have to be determined, etc. In the following, we call all these actions group rendezvous. In existing groupware systems, the group rendezvous is often neglected, i.e. it is assumed that a team has already formed, session information has been distributed and network paths are known. In reality, this assumption often does not hold: members with dial-up connections are not permanently online, if they get their network addresses from an address pool, e.g. via a network access provider, they are difficult to find even when they are online. This paper describes a fully decentralised group rendezvous system, which addresses these problems. Besides session distribution, the system has a component for resolving variable network addresses. It has been integrated into the synchronous groupware system DreamTeam [RU98].

A Network Address Translator (NAT) is a popular technological tool used in networks, especially in small-sized networks. Recently, network operators have been considering deploying Large Scale NATs (LSNs) to cope with IPv4 address pool exhaustion. This will make it necessary to deal with several problems related to LSNs, such as multiple levels of NATs (cascaded NATs) and the shortage of port numbers used by NATs. To address these issues, this paper extends the concept of UDP Multiple Hole Punching previously proposed by us. The use of our proposed method enables an accurate Port Prediction and reduces the number of open ports. The new method can determine the low TTL values for IP packets. We also discuss the application of i-Path routers, which provide status information about NATs along a network path for end hosts. The use of these routers makes it easier to perform NAT traversal.