APAN 2003 Autoconfiguration Technologies in IPv 6 Mobile

APAN 2003 Autoconfiguration Technologies in IPv 6 Mobile Ad Hoc Networks Jaehoon Jeong, ETRI paul@etri. re. kr http: //www. adhoc. 6 ants. net/~paul 1

Contents l l l l Introduction Unicast Address Autoconfiguration Multicast Address Allocation Multicast DNS Service Discovery Protocol Stack supporting MANET Autoconfiguration Conclusion References 2

Introduction l Mobile Ad Hoc Network (MANET) l MANET has dynamically changing network topology. l MANET partition and mergence may happen. § l There is no network administrator. l l In MANET, there are many points to consider unlike the Internet. The current Internet services, such as address autoconfigation and DNS, are difficult to adopt. So, Auto-configuration is necessary in MANET!! 3

MANET Auto-configuration l l l Unicast Address Autoconfiguration Multicast Address Allocation Multicast DNS Service Discovery MANET Autoconfiguration Multicast DNS l Service Discovery Unicast Address Autoconfiguration Multicast Address Allocation 4

Unicast Address Autoconfiguration 5

Introduction l Configuration of Unicast Address in Network Interface l Precedent step for IP networking l Methods of IP address configuration in network interface l l Manual configuration Automatic configuration l Consideration of IP address configuration l A unique address should be assigned. l Automatic configuration is needed for user’s convenience. l Addressing in MANET l Each mobile node is necessary to autoconfigure its IP address through DAD. l l A arbitrary address is selected. The uniqueness of the address is verified though Duplicate Address Detection (DAD). 6

Strong DAD l Definition l l l Ai(t) : Address assigned to node i at time t. For each address a != undefined, Sa(t) = {j | Aj(t) = a}. Condition of Strong DAD l Within a finite bounded time interval after t, at least one node in Sa(t) will detect that |Sa(t)| > 1. 7

Example of Strong DAD 1 st Try of Host A § MAC Address - a 9: bb: cc: dd: ee: ff § IPv 6 Address - fec 0: 0: 0: ffff: abbb: ccff: fedd: eeff MANET Prefix EUI-64 2 nd Try of Host A § 64 -bit Random Number – 1111: 2222: 3333: 4444 § IPv 6 Address - fec 0: 0: 0: ffff: 1111: 2222: 3333: 4444 MAC & IPv 6 Address of Host C § MAC Address – a 9: bb: cc: dd: ee: ff § IPv 6 Address - fec 0: 0: 0: ffff: abbb: ccff: fedd: eeff Host C Random Number Host B Host A NS message NA message Router Wireless Link Where NS : Neighbor Solicitation, NA : Neighbor Advertisement 8

Procedure of Strong DAD Generation of 32 -bit Random Number and 64 -bit Random Number Generation of Temporary address with MANET_INIT_PREFIX and 32 -bit Number §MANET_INIT_PREFIX Ø fec 0: 0: 0: ffff: : /96 Generation of Tentative address with MANET_PREFIX and 64 -bit Number §MANET_PREFIX Øfec 0: 0: 0: ffff: : /64 This iteration is performed by predefined retry-number. Transmission of Extended NS message Was any extended NA message received from any other node? YES Generation of 64 -bit Random Number NO Reconfiguration of Unicast address in NIC 9

Problem of Strong DAD - 1/2 IP address = a A F B C E D G H K IP address = a 10

Problem of Strong DAD – 2/2 IP address = a A F B C E D G H K IP address = a 11

Conclusion for Strong DAD l Simple Observation l l If partitions can occur for unbounded intervals of time, then strong DAD is impossible. Limitation of Charles E. Perkins’s DAD l When partitions merge, addresses of all nodes must be checked for duplicates. l l This DAD does not indicate how merging of partitions should be detected. This does not suggest how the congestion caused by DAD messages may be reduced. 12

Weak DAD l Requirements l Correct Delivery l l Packets meant for one node must not be routed to another node, even if the two nodes have chosen the same address. Relaxed DAD l It does not require detection of all duplicate addresses. § The duplication of addresses can not be detected in partitioned networks. 13

Definition l Assumption l l A packet sent by node X at time t to destination address a be delivered to node Y that has chosen address a. Condition l After time t, packets from node X with destination address a are not delivered to any node other than node Y. 14

Design Goals l Address size cannot be made arbitrarily large. l l IP header format should not be modified. l l It is wanted to add new options to the IP header. Contents of routing-related control packets may be modified to include information pertinent to DAD. l l MAC address cannot be embedded in the IP address. E. g. , Link state updates, Route request / reply. No assumptions should be made about protocol layers above the network layer. 15

Main Idea l Key is used for the purpose of detecting duplicate IP addresses. l l The key is not embedded in the IP address itself. Generation of Key l MAC Address l l Random Number l l When MAC address of an interface is guaranteed to be unique. A sufficiently large number of bits of making the probability of key conflict acceptably small Number derived from some other information l E. g. , Manufacture’s name and device serial number 16

Link State Routing with Strong DAD Routing table at node D A B C E D Dest Next Hop IP_B IP_C IP_E IP_A IP_B IP_E Link state packet transmitted by D From To Cost IP_D IP_E 2 IP_D IP_B 10 17

Link State Routing with Weak DAD Routing table at node D A B C E D Dest Key Next Hop IP_B K_B IP_C K_C IP_E IP_A K_A IP_B IP_E K_E IP_E Link state packet transmitted by D From Key To To Key Cost IP_D K_D IP_E K_E 2 IP_D K_D IP_B K_B 10 18

Resolution of Address Conflict by Weak DAD (IP address, Key) = (a, K_A) A F B C E D G H Duplication Advertisement K (IP address, Key) = (a, K_K) E detects the duplication of address a with key information (IP address, Key) = (b, K_K) 19

Hybid DAD l Combination of Strong DAD and (Enhanced) Weak DAD l Strong DAD detects duplicate address within a single connected partition. l Weak DAD processes the address conflict by MANET’s partition and mergence. l Hybrid DAD Scheme l It may detect some duplicate addresses sooner than using weak DAD alone. l The use of weak DAD makes it robust to partitions and large message delays in Strong DAD. 20

Phases of Hybid DAD l 1 st Phase l l l By Strong DAD l Time-based DAD It is performed in the stage for IPv 6 address to be configured in network interface. 2 nd Phase l l By Weak DAD It is performed during the routing process. l Router discovery in reactive Ad Hoc routing protocols, such as DSR and AODV. l Routing information exchange in proactive Ad Hoc routing protocols, such as OLSR and TBRPF. 21

Conclusion for Unicast Address Autoconfiguration l Requirements of Ad Hoc DAD l Correct Delivery l Packets meant for one node must not be routed to another node, even if the two nodes have chosen the same address. l Relaxed DAD l It does not require detection of all duplicate addresses. § l The duplication of addresses can not be detected in partitioned networks. Guarantee of Upper-layer session l Under the address change by DAD, the upper-layer session, such as TCP session, should be guaranteed to continue. 22

Multicast Address Allocation 23

Multicast Address Allocation l Role l l It allocates a unique IPv 6 multicast address to a session without address allocation server. Address Format l IPv 6 multicast (a) is generated on the basis of Interface ID of IPv 6 unicast address (b). 24

Procedure of Multicast Address Allocation Request of Multicast Address Allocation Generation of Unused Group ID Generation of a Multicast Address Delivery of the Multicast Address 25

Service of Multicast Application : Allocation of a unique Multicast Address for a new Session B A A B 1 2 4 C C 1 D Step E D 1 1 Unicast Address Autoconfiguration 2 Run of Video-conferencing Tool (e. g. , SDR) and Creation of a new Session -> Multicast Address Allocation 3 Advertisement of Session Information 4 MN A’s join to the new Session 5 MN E’s join to the new Session 6 Transmission of Video/Audio Data by MN A 7 Transmission of Video/Audio Data by MN E E 1 1 3 6 5 Action 7 26

Multicast DNS 27

Introduction l Name Service in MANET l MANET has dynamic network topology l Current DNS can not be adopted in MANET! § l Because it needs a fixed and well-known name server Idea of Name Service in MANET l All the mobile nodes take part in name service § § Every mobile node administers its own name information It responds to the other node’s DNS query related to its domain name and IP address 28

Related Work : Link-Local Multicast Name Resolution (LLMNR) l l DNS service based on IP multicast in link-local scoped network Each node performs the role of DNS name server for its own domain name. LLMNR Sender LLMNR Responder LLMNR query message (What is IPv 6 address of “host. private. local”? ) - It is sent in link-local multicast LLMNR response message (IPv 6 address of “host. private. local”) - It is sent in link-local unicast Verification of LLMNR response - Does the value of the response conform to the addressing requirements? - Is hop-limit of IPv 6 header 1? If the result is valid, then the Sender caches and passes the response to the application that initiated DNS query. else the Sender ignores the response and continues to wait for other responses. 29

Ad Hoc Name Service System for IPv 6 MANET (ANS) l ANS provides Name Service in MANET l Architecture of ANS System l ANS Responder l l It performs the role of DNS Name Server ANS Resolver l It performs the role of DNS Resolver 30

ANS System (1/2) 31

ANS System (2/2) Application ANS Resolver ANS Responder Main-Thread ANS Zone DB Resolv-Thread ANS Cache Timer-Thread DUR-Thread Process Thread Memeory Read / Write Process UNIX Datagram Socket Thread Memeory Read / Write Cache Internal Connection Database 32

Name Service in ANS l Name Generation l l Zone File Generation l l generates a unique domain name based on the network device identifier generates ANS zone file with the unique domain name and corresponding IPv 6 address Name Resolution l performs the name-to-address translation 33

Conclusion for Multicast DNS l ANS is a new name service scheme in MANET. l Name service of ANS l l Automatic name generation Automatic zone file generation Name-to-address translation Future work l ANS will be enhanced to provide secure name service. l Authentication of DNS response message through Pre-shared group key and IPsec ESP’s null-transform 34

Service Discovery 35

Service Discovery l Definition l l Discovery of the location (IP address, Transport-layer protocol, Port number) of server that provides some service. Methods l Multicast DNS based Service Discovery § l Service discovery through Multicast DNS and DNS SRV resource record, which indicates the location of server or the multicast address of the service SLP based Service Discovery l Service discovery through IETF Service Location Protocol (SLP) § RFC 2165, RFC 2608, RFC 3111 36

Considerations for Service Discovery l Limitations of Existing Schemes l l Most of current schemes are concerned with service location for the Internet. l Such protocols have not taken into account the mobility, packet loss issues and latency. Considerations l l Some devices are small and have limited computation, memory, and storage capability. l They can only act as clients, not servers. Power constraints l Service discovery should not incur excessive messaging over wireless interface. 37

Service Discovery based on Multicast DNS ANS Responder’s Zone File $TTL 20 $ORIGIN ADHOC. PAUL-1 IN IPv 6 Multicast Address corresponding to Service Name AAAA FEC 0: 0: 0: FFFF: 3656: 78 FF: FE 9 A: BCDE 8 ; ; DNS SRV Resource Records ; Unicast Service : SERVICE-1 _SERVICE-1. _TCP IN SRV 0 1 3000 PAUL-1. ADHOC. _SERVICE-1. _UDP IN SRV 0 1 3000 PAUL-1. ADHOC. FF Flags P=0, T=1 ; Multicast Service : SERVICE-2 _SERVICE-2. _UDP IN SRV 0 1 4000 @. 1. 5. Generation of IPv 6 Multicast Address 4 4 DNS SRV Resource Record for Multicast Service Name Parsing Function MD 5 Hash Function Flags label & Scope label 128 -bit Digest 16 -bit IPv 6 Site-local Multicast Address Prefix + 112 Group ID Scope 5 Group ID=Low-order 112 bits of Digest IPv 6 Site-local Multicast Address 38

Scenario of Service Discovery MN-C MN-A MN-B Request of Server Information DNS Query Message for Service Information DNS Query Message is sent in Multicast DNS Query Message for Service Information Receipt of DNS Query Message DNS Response Message with Service Information Receipt and Process of DNS Query Message related to DNS SRV resource record Gain of Service Information MN-C tries to connect to the server on MN-A or MN-C joins the multicast group related to MN-A The server on MN-A accepts the request of the connection from MN-C or The multicast group comprises MN-A and MN-C 39

Protocol Stack supporting MANET Autoconfiguration 40

Conclusion l MANET Autoconfiguration l l l Unicast Address Autoconfiguration Multicast Address Allocation Multicast DNS Service Discovery Autoconfiguration Technologies in MANET l l l They can provide Ad Hoc users with auto-networking. They should be default functions for the deployment of MANET. Also, security in MANET is important issue and is considered together in auto-networking in MANET. 41

References [1] Jaehoon Jeong, Hyunwook Cha, Jungsoo Park and Hyoungjun Kim, “Ad Hoc IP Address Autoconfiguration”, draft-jeong-adhoc-ip-addr-autoconf-00. txt, May 2003. [2] Nitin H. Vaidya, “Weak Duplicate Address Detection in Mobile Ad Hoc Networks”, Mobi. Hoc 2002, June 2002. [3] Charles E. Perkins et al. , “IP Address Autoconfiguration for Ad Hoc Networks”, draftietf-manet-autoconf-01. txt, November 2001. [4] Jaehoon Jeong and Jungsoo Park, “Autoconfiguration Technologies for IPv 6 Multicast Service in Mobile Ad-hoc Networks”, 10 th IEEE International Conference on Networks, August 2002. [5] Jung-Soo Park and Myung-Ki Shin, “Link Scoped IPv 6 Multicast Addresses”, draft-ietfipv 6 -link-scoped-mcast-02. txt, July 2002. [6] Jaehoon Jeong, Jungsoo Park, Hyoungjun Kim and Kishik Park, “Name Service in IPv 6 Mobile Ad-hoc Network”, ICOIN 2003, February 2003. [7] Gulbrandsen, P. Vixie and L. Esibov, “A DNS RR for specifying the location of services (DNS SRV)”, RFC 2782, February 2000. [8] Jaehoon Jeong, Jungsoo Park, and Hyoungjun Kim, “Service Discovery based on Multicast DNS in IPv 6 Mobile Ad-hoc Networks”, VTC 2003 Spring, April 2003. 42