7/27/2019 10.1.1.83.7673

1/11

Enhancing Hierarchical Mobile IPv6

Addressing for the Annex Architecture

D.A. Grove1, M. Anderson1, and C.J. North1

Defence Science & Technology Organisation,PO Box 1500, Edinburgh, South Australia 5111

{duncan.grove, mark.anderson, chris.north}@dsto.defence.gov.au

Abstract. We present a new Hierarchical Mobile IPv6 based addressingscheme for an advanced experimental network, called Annex. This ad-dressing scheme provides backward compatibility with standard InternetProtocols, but has been enhanced to allow fine-grained access control andnetwork aware routing in order to provide improved security, real-timeperformance and robustness for communication between Annex-awaredevices.

1 Introduction

The Information Networks Division in the Defence Science and Technology Or-ganisation is developing an advanced experimental network, called Annex [1],which aims to provide enhanced connectivity between military forces as well as

seamless connectivity to civilian entities using standard Internet Protocols. An-nex is based on IPv6 with Hierarchical Mobile IPv6 extensions. This allows forauthentication and encryption using IPSec, provides flow markers to assist inthe efficient management of streaming data, and supports addressing for mobilenodes. While maintaining full backward compatibility, we extend Annex enabledsystems to include very fine-grained access control and network awarepropertiesvia a capability based system [2]. Annexs on the fly network aware routing in-troduces methods for improving real-time performance, robustness and securityfor communication between Annex enabled devices.

Our modifications to HMIPv6 utilise a unique naming system for all entitiesin the Annex network. Thus, a personal communications device could be issuedto each member of the Australian Defence force, each with a unique identifier

embedded in its IPv6 address, thereby achieving strong identity bindings. Inaddition, we believe that throw-awayappliance devices will become common,but these will still require a unique one-time naming for security tracking andlogging. This has resulted in the need for a sparse address allocation method, asdescribed in the rest of this paper.

c Commonwealth of Australia

7/27/2019 10.1.1.83.7673

2/11

1.1 IPv6

The driving reason for the introduction of IPv6 [4] is to avoid the impending ex-haustion of the IPv4 address space, especially in Asia, which has been achievedby increasing the IP address space from 32 to 128 bits. Part of the reason for thegrowing shortage of IPv4 addresses is that the designers of IPv4 did not envisagehow ubiquitous IP would become, moving beyond just a small number of spe-cialised computers to a global network of PCs, phones, fridges, etc. Interestingly,the address space allocation requirements surfacing in the Annex design suggestthat the IPv6 address space may not turn out to be as copious as one mightthink.

Compared to its predecessor, IPv6 was also designed with improved routingperformance in mind. While IPv6 headers are slightly larger than their IPv4counterparts (due to the increased size of source and address fields), they havea much simpler structure and contain many less options by default. This means

that IPv6 packets can potentially be far more efficiently processed by specialisedrouting hardware. When extra functionality is required, IPv6 employs extensionheaders, which are chained on to the end of the main IPv6 header. Thus, theseextension headers are only included and hence processed when necessary. IPv6network allocation policies also require route aggregation, where prefix alloca-tions are hierarchically assigned so that the number of routes that must beremembered by the Internets core routers is minimised. This is in stark con-trast to IPv4 network allocation, where any organisation may connect a subnetthat it owns to arbitrary parts of the Internet, which has lead to an exponentialexplosion in the size of core routing tables.

1.2 Mobile IPv6

Mobile IPv6 (MIPv6) [8] was introduced to cater for computers which maychange their point of attachment to the network, for example when shiftingto a new physical location. A fixed entity known as a home agent is required tointercept all messages destined for the fixed global addresses of any mobile nodesunder its care, and to forward those messages on via each mobile nodes care-ofaddress. Every time a mobile node moves to a new location it must acquire anew care-of address and inform its home agent about this new address using abinding update. In Mobile IPv6, mobile nodes acquire new care-of addresses usingstateless autoconfiguration. Statelessly autoconfigured addresses are generatedat the mobile node by concatenating the 64 bit network prefix of the networkbeing visited with the mobile nodes unique 64 bit host identifier. The 64 bit

prefix of the network being visited can be obtained by waiting for or soliciting arouter advertisement message from a router or router advertisement daemon onthe network segment being visited.

A serious limitation of Mobile IPv6 is that binding updates can take a longtime if a mobile node is far away from its home agent. While this is not necessarilya serious issue for nodes that only change location periodically and at a sedatepace, during this handover period, significant amounts of data being streamed

7/27/2019 10.1.1.83.7673

3/11

to (and in some cases from) highly mobile nodes (such as phones) may arrivelate or be lost altogether. These types of interruptions can seriously degrade the

user experience.

1.3 Hierarchical Mobile IPv6

Hierarchical Mobile IPv6 (HMIPv6) [3] was designed to reduce the long hand-off time associated with MIPv6 [5]. HMIPv6 introduces the notion of MobilityAnchor Points (MAPs) which serve as local points of contact for mobile nodesduring binding updates. In order for this to work, a mobile node only informs itshome agent or any correspondent nodes of changes to its MAP rather than itsactual care-of address. In addition to this, though, it must inform its MAP of any

changes of its actual care-of address. This can be done more quickly, however,if the MAP is nearby, as it is supposed to be. Any data destined for a mobilenode must be routed (tunnelled) via its MAP because only the MAP will knowthe current care-of address of the mobile node. Thus, binding updates can be-come more local and data flow to mobile nodes is less interrupted. MAP-basedbinding updates can also be combined with smooth hand-over, where a mobilenode obtains a new care-of address before relinquishing its old one, and acceptsdata sent to both addresses until the handoff is complete, thus minimising dataloss.

In HMIPv6 it is possible to create arbitrary MAP hierarchies between homeagents and mobile nodes. When this is done, binding updates need only propa-gate as far up the MAP hierarchy as is necessary in order to record the current

location of a mobile node. This can work well if users typically exhibit muchmore local movement than global movement. Note also that there is no require-ment for all (or any) of the intermediate routers between mobile nodes and homeagents to be MAP-enabled, although only those that are MAPs will be able toreduce the hand-off latency of mobile nodes beneath them in the hierarchy.

A significant problem with HMIPv6 in our military context, however, is thatit uses a static MAP hierarchy where communication from every level of MAPto the next requires a new encapsulation tunnel for message forwarding. Thiswould have three drawbacks if it were used in the Annex architecture. Firstly,it increases the processing and bandwidth requirements of intermediate routers.Secondly, tunnelling makes it very difficult to keep track of and honour IPv6header flags. Finally, the routing topology is constrained, which makes dynamic

alterations that improve performance, robustness, security and/or other charac-teristics difficult. For example, if a mid-level MAP becomes unreachable (whichis not uncommon in military deployments) all mobile nodes beneath it in thetree will become unreachable until they discover this and obtain new care-of ad-dresses from a new hierarchy of MAPs, which may take some time. It would bedesirable for the network (MAPs) to detect this and immediately divert trafficthrough some other hierarchy.

7/27/2019 10.1.1.83.7673

4/11

2 IPv6 Addressing in Annex

Annex Networks are envisaged to operate on a global scale with multiple levelsof mobility between end user devices and the supporting network infrastructure.Some method will be required to provide acceptable QoS for real-time datadelivery to mobile nodes that are far removed from their home agents. While itseems that Hierarchical Mobile IPv6 will solve many of the problems caused bythe global mobility of Annex devices, several slight modifications and extensionsmay be beneficial. To highlight these it is first necessary to explain how Annexwill make use of existing Hierarchical Mobile IPv6 techniques.

2.1 IPv6 Address Partitioning

One of the most important facets of how Hierarchical Mobile IPv6 protocolswill be used in Annex is the way in which addressing information will be par-

titioned. Annex uses IPv6 address space in a slightly unusual way. Unlike thecompacted use of address space that is the norm in IPv4, Annex employs a moresparse address allocation policy. This is done for two reasons: firstly, so thatnodes can be uniquely identified, regardless of their point of attachment to thenetwork; and secondly, to exploit the structured network topologies that tendto emerge in large organisations, for the purpose of enhancing routing efficiencyand functionality.

Table 1. IPv6 address partitioning for Annex networks

Prefix Family BriccL1 BriccL2 Reserved Dev ID

32 8 16 8 16 48

Table 1 shows the structure of an Annex devices address, with suggested bitallocations. From a backwards compatibility perspective, the only hard require-ment of this address allocation scheme is the 64/64 bit partitioning between theso-called network part (the left-most 64 bits) and host part (the right-most 64bits), which is required for stateless autoconfiguration and thus Mobile IPv6 tofunction. There is, however, scope to further partition each of the network andhost parts as required, although Annex requires that a devices prefix and DevID never change.

Prefix Allocation.The prefix field represents the fixed part of the IPv6 addressspace that will be supplied by an Internet allocation authority and represents the

entire Annex domain. In a full implementation, the prefix would represent theentire Australian department of Defence including all service arms, fixed infras-tructure, Intelligence, Surveillance, Reconnaissance (ISR) and weapons grids. Itis not unreasonable to believe that a 32 bit IPv6 prefix could be acquired tosupport a possible final incarnation of the Annex network.

7/27/2019 10.1.1.83.7673

5/11

Family Addresses. The family field is used to partition the global Annexaddress space into a number of domains or high level networks, where each

typically maintains its own independent administrative control, routing, security,and service requirements. Each family would maintain its own home agent (orperhaps some pool of home agents) through which it could allocate addresses toand/or administer mobile devices and Briccs within its domain. Typical uniquefamily designators may be Navy, Air Force, or Army. In addition, some familyIDs may be reserved for transient use, for example to support some operationalpurpose.

Bricc Addresses. In Annex, Briccs are network infrastructure devices thatprovide a range of network and security services using password capabilities,which provide a general mechanism for fine grained access control [2]. Eachfamily assigns their own BriccLn fields to oversee routing, service handling, andstructure within their own networks. In particular, these BriccLn should describethe particular routing system that is employed by each individual family. Briccfields can change dynamically in accordance with family defined policies.

The example address partitioning shown in Table 1 describes and promotesa two level (i.e. fairly flat) routing hierarchy, although more levels could be used.Ideally, each Bricc at each level of this hierarchy would be a MAP, thus sup-porting very efficient mobility of end user devices. In addition, Briccs should bedesignated as either L1 or L2 Briccs depending on their role; Briccs at L1 shouldtend to be more fixed with regard to the routes that they administer, whileBriccs at L2 would tend to be more mobile. This hierarchical partitioning, withfixed size bit-spaces, into fixed Briccs at BriccL1 and mobile Briccs at BriccL2permits routing functions to be relatively easily implemented in simple hardware

for very high performance operation. It is also compatible with hierarchical AdHoc routing and addressing schemes which are particularly suited to battlefieldnetworks, for example [7]. Alternatively, however, the BriccLn bit-space could beused for traditional IPv6 prefix routing within a family, thus supporting moreflexible routing at a greater cost.

Device Addresses. The host part in the lower 64 bits of the IPv6 addresscontains the unique identity of any device (or Bricc) within the Annex network.This address remains unchanged for the lifetime of the unit and is never re-used. In normal IPv6 implementations, a devices unique 64 bit host identifieris usually derived from the hash of some unique physical tag, such as a 48 bit

Ethernet MAC or Bluetooth address. In Annex, however, the upper 16 bits ofa devices unique host address is reserved, and therefore only 48 bits of Dev IDwill be available to distinguish devices uniquely, thus supporting the issue ofjust over 281x1012 discrete Annex units. Together these 16 bits of reserved spaceand 48 bits of Dev ID produce a 64 bit host part that ensures the Annex systemremains fully compatible with open IPv6 and Mobile IPv6 standards. For Annexdevices, the unique 48-bit host identifier is fixed at device manufacture.

7/27/2019 10.1.1.83.7673

6/11

2.2 IPv6 Routing in Annex

Because Annex devices can be uniquely distinguished by their globally unique64 bit host part and their current family, any device can be addressed by ut-tering its tuple, regardless of the value of theBriccLn field(s). In particular, however, the /64 part ofany Annex familys network is required to act as the home network for thatfamily. Hence, any device can be contacted at its home address by zeroising theBriccLn fields in the tuple described above. If a correspondent node or interme-diate router has a better idea about the current location of a device, however(i.e. it has any BriccLn stored in its binding update tables) it can utter the tuplewith that information to facilitate more direct routing. This is depicted in thesrc addr and dst addr fields in Table 2, where device A is addressing device B.

Table 2. Uttering IPv6 addresses in Annex

IPv6 Header Addressing Information

Src addr Dst addr Home Addr Opt Dest addr

Uttering an address tuple describes a special form of IPv6 header construc-tion, where source and destination addresses are each stored twice within theIPv6 header. The first source/destination pair corresponds to the source/destination pair found in a normal IPv6 header, and should (initially) contain

the sending devices care-of address and the recipients care-of address if it isknown, or home address (i.e. where BriccLn is zeroised) if it is not. Unlike tra-ditional [H]MIPv6, these addresses are mutable. The second source/destinationpair should be stored in an IPv6 Destination Option extension header, and shouldcontain the sending devices home address and the recipients home address.These addresses are immutable. When the packet is finally delivered to the des-tination device, the main IPv6 headers source/destination pair will be replacedwith the copies in the extension header and passed up to higher level processingas though the communication occurred directly between the two devices homeaddresses.

Storing the home address of the source device in the extension header isessentially the same as using a Home Address option in normal MIPv6 to allow

outgoing packets to pass ingress filtering tests. Storing the home address of thedestination device in the extension header is essentially the same as using a type2 Routing Header in normal MIPv6 to provide route optimisation. Note thatthese two options are not used together in standard [H]MIPv6 operation in away that allows the main IPv6 headers source/destination address pairs to bemodified en-route. If IPSec authentication is being used, care must be taken toensure that the Authentication Header is created and verified with the same

7/27/2019 10.1.1.83.7673

7/11

sets of predictably mutable source/destination address pairs in the main headerand extension header. In addition, where ICMP status messages are generated

in response to an uttered packet (eg for IPv6 path MTU discovery), care mustbe taken to route that response back to the home source address stored in thepackets extension header.

Uttering, as described above, requires 4 x 16 = 64 bytes of addressing infor-mation per IPv6 packet, as opposed to 2 x 16 = 32 bytes for normal IPv6, oreither 3 x 16 = 48 or 4 x 16 = 64 bytes of addressing for normal [H]MIPv6 (64for the common case when both nodes are mobile and the sender has a routeoptimisation binding for the recipient). Note however, that plain IPv6 doesntprovide mobility support, MIPv6 doesnt provide the improved hand-off timeof HMIPv6 required for real-time communications, and HMIPv6 doesnt allowRouting Header optimisations to be applied for every level in the MAP hierarchy.

Network Aware Routing. Whereas normal HMIPv6 must encapsulate suchcommunication in a new tunnel for every level of MAP, Annex MIPv6 routingallows the source/address pair in the main IPv6 header to be modified at willby intermediate Annex-MAPs. The simplicity afforded by avoiding the need toprocess extension headers/tunnel packets at every MAP will allow Annex-MAProuters to employ specialised hardware to perform very fast rerouting of Annex-MIPv6 packets according to information stored in the MAPs binding caches. Inaddition, avoiding the use of preconfigured tunnels between MAPs means therouting topology may be dynamically altered to improve performance, robust-ness, security and/or other network characteristics. Such network awareness isvery important in the military context, where directed threats against a com-munications network whose devices, infrastructure and methods of connectivity

at differing service levels can change rapidly.In addition to utilising Hierarchical IPv6 Annex-MAP functionality, Annex

devices can directly address other devices within a given MAPs sub-tree withoutinvolving the destination devices home agent: a source device need simply utter amessage addressed to the unique host part of another device and a specified MAP.If the uttered device is being actively managed by that MAP (either directly orindirectly via some hierarchy) the message will be routed appropriately, as allMAPs know how to route towards devices beneath them in the MAP hierarchyif they are bound. Alternatively, if it is not, an Annex-augmented MAP maydecide, depending on policy and/or other information contained in the messagesIPv6 header, to report failure or possibly zeroise (or broadcast on) one or moreBriccLn fields and forward the packet on to broaden the search space for the

destination device. The downward broadcast mechanism (for example used by aL1 Bricc to its L2 Briccs) means that the L1 Bricc need not maintain a completelist of all devices beneath it in the hierarchy at all times, but can search for them(by paging them [9]) on demand if required. For efficiency reasons, however, anL1 Bricc should cache the L2 location information for any devices with activedata flows, for example indexed by their IPv6 flow marker. Further, the scope ofany downward (or potentially upward) search for a device must be constrained

7/27/2019 10.1.1.83.7673

8/11

to prevent network overload and potential Denial of Service attacks, but this isconveniently provided for using moneyin Annexs password capability system [2].

The augmented MAP functionality described above will provide Annex withmore robustness and power than standard Hierarchical Mobile IPv6. Firstly, itprovides a mechanism for packets to be very efficiently routed within the Annexdomain. Secondly, it will give Annex devices the ability to contact other devicesif they are reachable, whether their home agents are available or not, whichis useful in a battlefield situation where local network connectivity has beenmaintained but the connection to remote network elements has been severed.Finally, it can be used to support the allegiance-swap of Annex devices. In Annex,a device and its globally unique host ID will be issued to an individual. Initiallythat individuals ID will be registered to a particular home agent, i.e. belongto a particular family. If, however, that individual changes their allegiances andjoins some other organisation, it is envisaged that they would take their devicewith them. In this case, their personal unique Annex ID would be registeredwith some new familys home agent(s). Now, where cooperation exists betweenfamilies, policy could allow messages uttered to a particular unique Dev ID andpropagated all the way up to the home agent level to be forwarded on to thehome agents of other families, thus allowing individuals to always be reachableregardless of their current allegiance.

2.3 An Example

Figure 1 depicts a scenario where mobile devices may connect to separate Logistic(L) and iNtelligence (N) networks, each of which are supported by a numberof Briccs. The HQ Briccs are home agents located at a central HeadQuarters,the CC Briccs are located at a Command Centre, the SAT Briccs represent a

SATellite routing network and the F Briccs are located in the Field. The F1,0Briccs are L1 fixed Briccs and the F1,n Briccs are L2 mobile Briccs. Separatebut colocated networking is common in military networks, which often requiredifferent services or security guarantees from a particular network even thoughtheir routers may be in very similar physical locations. In our example, theintelligence Briccs provide strong trunk encryption facilities, significant physicalsecurity mechanisms and use special routing algorithms for security reasons. Thelogistic Briccs, on the other hand, make more extensive use of COTS technologyin order to improve their cost effectiveness.

Imagine that user A wishes to contact user B and that A and Bs devicesare both registered with the intelligence family. Suppose that A has presentedcapabilities for access to NCC (1) and that B has presented capabilities for access

to LF1,1 (2). B will acquire a Link Care-of-Address (LCoA) on the logisticsnetwork from LF1,1 and a Regional Care-of-Address (RCoA) from LF1,0. B willthen bind its RCoA to its LCoA on LF1,0 so that LF1,0 can route traffic that isaddressed to Bs Dev ID. Depending on policy, B may also send a binding updateto NHQ to bind its home address to its RCoA. Alternatively, it may request abinding on LHQ to avoid revealing its allegiance to the intelligence family whileconnected to the logistics network.

7/27/2019 10.1.1.83.7673

9/11

NF1,0 LF1,0 LF1,1 LF1,2 LHQ NHQ

LFCC

NCC

LSAT

NSAT

MANET

A

B

C

24 5

6

3 1

Fig. 1. Example of how to address a mobile device.

If Bs RCoA is bound on NHQ then A can contact B directly though theintelligence network. The security policies applied by B or intermediate MAPsmay allow a binding update to be sent to A to facilitate route optimisation.Alternatively, if Bs RCoA is not bound on NHQ then packets sent from A that

are addressed to B will be captured by NHQ which may, depending on securitypolicy: 1) inform A that Bs whereabouts is unknown; and/or 2) suggest possibleallied home agents or Briccs where B might be reachable; and/or 3) forward thepacket on to those home agents or Briccs. Hence, Annex devices, home agentsand Briccs can enforce special routing policies when desired. For example, byutilising the password capability system, routers on the intelligence network maybe configured so that only some types of traffic are allowed to enter or leave theintelligence network. A similar policy mechanism could provide network awarerouting by using metrics such as how much processing power, bandwidth orconnectivity Briccs have available to them.

Consider the case where B chose to bind its RCoA on LHQ and where NHQknew that B could often be found on the logistics network. If A tried to contact

B through the intelligence network, NHQ could inform A to try addressing Bvia LHQ. A could then connect to LCC (3), register its own care-of addresses onthe logistics network and thus contact B using logistics network resources. If Aand B wished their connection to be routed entirely through intelligence networkBriccs then they could simply re-connect to NCC (1) and NF (4), respectively,and re-establish communication, which would be transparent to higher protocollayers.

7/27/2019 10.1.1.83.7673

10/11

Taking this example further, A and B could then detach from NCC andNF and re-establish a connection through logistic Briccs once more. B could

then move off through the more extensive logistics network to reach some otherlocation. For example, B could have performed a handoff to mobile Bricc LF1,2(5) which was located in a transport helicopter and been delivered to a remotelocation serviced only by an Ad Hoc network disjoint from logistics or intelligenceBriccs. Despite this, B could establish a connection (6) to some intelligencedevice C by querying any local MAPs for Cs Dev ID, even though NHQ wasunreachable.

3 Related Work

The IETF sponsors a broad range of working groups [6], many of whose goalsoverlap with those of Annex. In terms of addressing, the most important of

these working groups are Internet Protocol Version 6 (ipv6), Mobility for IPv6(mip6), MIPv6 Signalling and Handoff Optimization (mipshop), Context Trans-fer, Handoff, Candidate Discovery, and Dormant Mode Host Alerting (seamoby),Mobile Ad-hoc Networks (manet) and IP Flow Information Export (ipfix). Sig-nificantly, these groups have defined IPv6 and [H]MIPv6. In terms of security,the most important working groups are IP Security Protocol (ipsec), Authentica-tion, Authorization and Accounting (aaa), Protocol for carrying Authenticationfor Network Access (pana), IP Security Policy (ipsp), Routing Protocol SecurityRequirements (rpsec), and Securing Neighbour Discovery (send).

Many of the IETF specifications in this area continue to receive contributionsfrom researchers working on various [H]MIPv6 stacks. These include the MobileIPv6 for Linux (MIPL) stack, and stacks in development by Cisco Systems,

Ericcson, Nokia and Microsoft.We find it interesting that there are so many IETF working groups spreadacross two broad notions: mobility and security. Annexs password capabilitysystem is being designed to provide a single mechanism that can interoperatewith standard IPv6 protocols yet also delivers the desirable properties of manyof the working groups goals.

4 Conclusion

This paper described the design of the fundamental addressing scheme for theexperimental Annex network. The design is based on Hierarchical Mobile IPv6and supports enhancements for route optimisation and fast hand-overs for mo-

bile nodes. The address allocation scheme was designed to support the notionof families, which can exercise control over routing and services provided todevices within their administrative domains. Annex extensions to HierarchicalMobile IPv6 allow (according to policy) devices to be contacted even when theirowners have changed allegiance and joined a new family or when a network be-comes temporarily disjoint. These modifications also permit on-the-fly addressmodification for network aware routing that can enhance the security, real time

7/27/2019 10.1.1.83.7673

11/11

performance and robustness of communication between Annex-aware devices.These extensions can be implemented while retaining seamless interoperability

with non Annex devices and routers.The Annex addressing scheme utilises unique identifiers for all units in the

network, which creates opportunities for powerful security mechanisms to beimplemented, but it results in a sparsely populated IPv6 address space. Whilethe number of devices that can be supported in this architecture is very large,the total number of Families and Briccs that can be supported is small enoughto be of concern in the long term. Further addressing schemes which result in asparsely populated space may run into similar issues. It is interesting to note thateven before IPv6 becomes ubiquitous in the Internet, there are already attemptsto use the address space in a manner which may not have been fully envisagedby its designers.

References

1. Anderson M., et al.: Annex: An Overview. Forthcoming.2. Anderson, M., Pose, R., Wallace, C.S.: A password-capability system. The Computer

Journal 29 (1986) 18.3. Castelluccia, C.: HMIPv6: A Hierarchical Mobile IPv6 Proposal. ACM SIGMOBILE

Mobile Computing and Communications Review 4(1) 2000 4859.4. Deering, S., Hinden, R.: Internet Protocol, Version 6 (IPv6) Specification. RFC

2460, December 1998.5. Forsberg, D., Malinen, J.T., et al: Distributing Mobility Agents Hierarchically under

Frequent Location Updates. Proc. Sixth IEEE International Workshop on MobileMultimedia Communications (MoMuC), San Diego, November 15-17, 1999.

6. IETF working groups: aaa, ipfix, ipsec, ipsp, ipv6, manet, mip6, mipshop, pana,

rpsec, seamoby, send. http://www.ietf.org/html.charters7. Pei, G., Gerla, M.: Mobility Management for Hierarchical Wireless Networks. MobileNetworks and Applications 16(4) (2001) 331337.

8. Perkins, C.E., Johnson, D.B.: Mobility Support in IPv6. Proc. MobiCom96, Rye,New York, November 10-12, 1996; also see draft-ietf-mobileip-ipv6-24.txt

9. Zhang, X. and Castellanos, J.G., Campbell, A.T.: Design and Performance of MobileIP Paging. ACM Mobile Networks and Applications (MONET), Special Issue onModeling Analysis and Simulation of Wireless Mobile Systems, 7(2) (2002).