International Research Journal of Engineering and Technology (IRJET) e-ISSN:2395-0056
Volume: 12 Issue: 04 | Apr 2025 www.irjet.net p-ISSN:2395-0072
SmartAddr: Dynamic IPv6 Addressing for Secure IoT Communication
Rozeeta Fernandes1, Riya Kasture2, Anushree Dere3, Srushti Gaidhane4, Varshapriya Jyotinagar5
1B. Tech Student, Dept of Computer Engineering and IT, VJTI College, Mumbai, Maharashtra, India
2B. Tech Student, Dept of Computer Engineering and IT, VJTI College, Mumbai, Maharashtra, India
3B. Tech Student, Dept of Computer Engineering and IT, VJTI College, Mumbai, Maharashtra, India
4B. Tech Student, Dept of Computer Engineering and IT, VJTI College, Mumbai, Maharashtra, India
5Assistant Professor, Dept of Computer Engineering, and IT, VJTI College, Mumbai, Maharashtra, India
Abstract - With the increasing deployment of IoT devices, the security of IoT servers continues to face significant challenges. Building upon the concept of an addressless IoT server, this paper presents an improved algorithm that enhances the original design using dynamic IPv6 suffix generation. Instead of assigning a fixed IPv6 address to the server, only a constant IPv6 prefix is allocated. When a client initiates communication, it uses an encryption mechanism to generate a specific destination address under this prefix. The server verifies the address upon receiving a packet and discards it if verification fails. The improved algorithm introduces a more efficient validation mechanism and optimized address generation logic to reduce the chances of packet drops caused by timing mismatches. The proposed improvements aim to enhance security, reduce exposure to scanning attacks, and improve communication reliability in dynamic IoT environments.
Key Words: IPv6, IoT, server security, dynamic addressing, client authentication
1.INTRODUCTION
1.1
Rise of ipv6 in IoT era
TherapidexpansionoftheInternetofThings(IoT)has led to an unprecedented demand for IP addresses, as billions of smart devices require unique identification to communicateovernetworks.Thelimitedaddressspaceof IPv4 (approximately 4.3 billion addresses) is insufficient to support this scale, prompting the global transition to IPv6, which offers a vastly larger address space of 2¹²⁸ addresses[1].IPv6alsointroducesfeatureslikesimplified header formats, stateless address autoconfiguration, and improved routing efficiency all of which are essential for scalable and reliable IoT deployments [2]. As a result, IPv6 adoption is becoming increasingly critical for the futureofsecureandefficientIoTecosystems.
1.2 IoT Server Security
Secure IoT ecosystems rely not only on device-level protections but also on the robustness of IoT servers, which act as central hubs for data exchange, control, and
decision-making. These servers are frequent targets of cyberattacks such as scanning, spoofing, and denial-ofservice (DoS) due to their predictable IP addressing and constant network presence. Traditional security mechanisms,whileeffectivetosomeextent,oftenstruggle to scale with the vast number of connected devices and dynamic communication patterns in IoT networks [3]. As servers play a crucial role in processing sensitive information and maintaining system integrity, ensuring their security is foundational to the reliability and trustworthinessoftheentireIoTinfrastructure[4].
1.3 Motivation for “Addressless” IoT servers
Traditional IoT servers typically use static or predictableIPaddresses,whichareoftenstoredinrouting tables or DNS records, making them easy targets for network scanning, spoofing, and denial-of-service attacks [5].Thesefixedaddressesexposetheserver’spresenceon thenetwork,allowingattackerstodetectandexploitthem. To address this vulnerability, the concept of addressless IoT servers has emerged, where the server is assigned only a dynamic IPv6 prefix, and the actual destination address is generated on-the-fly by the client using cryptographic methods. This approach effectively hides the server from unauthorized users, enhances resistance to scanning, and adds an extra layer of security through addressverification[6].Suchdynamicaddressgeneration leverages the vast IPv6 space, making targeted attacks significantlymoredifficult.
The upcoming sections of this research paper are structured as follows: Section 2: Literature Survey presents an overview of existing algorithms relevant to IoTserversecurityandhighlightstheirlimitations.Section 3: Addressless Server Model from Literature explains the algorithm proposed by Liu et al., which outlines a theoretical approach for enhancing IoT server security using dynamic IPv6 addressing. Section 4: Improvement and Proposed Algorithm introduces our modified approachaimedataddressingtheidentifiedshortcomings, along with a conceptual block diagram for clarity. Section 5: Conclusion and Future Scope summarizes the key findings of this research and outlines potential directions
International Research Journal of Engineering and Technology (IRJET) e-ISSN:2395-0056
Volume: 12 Issue: 04 | Apr 2025 www.irjet.net p-ISSN:2395-0072
for further development. Finally, Section 6: References lists all the sources consulted and cited throughout the paper.
2. LITERATURE SURVEY
2.1 Issues in Traditional IoT Server Architectures
Traditional IoT servers often rely on static or predictableIPaddresses,whichmakesthemvulnerableto scanning, spoofing, and distributed denial-of-service (DDoS) attacks [7]. Once attackers identify the IP address of an IoT server, they can directly target it, disrupt services, or attempt to take control of connected devices. Recent work by Al-Hawawreh et al. [21] achieved 98.7% detection accuracy for such IPv6-based attacks using LSTM models, though runtime overhead remains challenging for low-end devices. These problems are amplified in large-scale deployments where hundreds or thousands of devices may be online and accessible. Static address assignments also create challenges for mobility, scalability,andprivacy critical concernsin modernIoT applications [8], [9] exacerbated by the lack of cryptographic identity binding in legacy protocols [18]. IPv4'slimitedaddressspacehashistoricallyforcedtheuse of NAT (Network Address Translation), which introduces furthercomplexityandlimitsend-to-endcommunication.
To overcome these challenges, IPv6 offers promising features like a vast address space and built-in autoconfiguration. These capabilities make it ideal for enablingsecure,dynamicaddressinginmodernIoTserver designs.
2.2 Role of IPv6 in Iot servers
To address these issues, researchers have proposed dynamic address generation methods, where IoT server addresses are generated on demand, often using encryption or cryptographic techniques. These methods alignwellwithIPv6,whichoffersavastaddressspaceand supports stateless address autoconfiguration (SLAAC) [10]. However, many dynamic schemes are still at the prototype stage and are rarely deployed at scale. Key challenges include keeping addresses discoverable to authenticated clients while hidden from attackers, particularly in edge computing scenarios where Wang et al. [20] showed fog-based prefix delegation can reduce DDoS attack surfaces by 62% and ensuring smooth integration with the TCP/IP stack particularly regarding latency, caching, and routing [11], [12]. Despite their potential, such methods need further refinement for practicaldeployment.
2.3 Dynamic Address Generation: Existing Methods and Proposals
Dynamic address generation techniques have been widelyexploredasameanstoimproveIoTserversecurity byreducingthepredictabilityofnetworkendpoints.Liuet al.introducedtheAddresslessIoTservermodelusingIPv6 prefix-based dynamic address generation [11]. Instead of assigningafullIPaddress,theserveronlyretainsaprefix, while authenticated clients generate valid destination addresses using encryption. This model enhances resistance to scanning and spoofing while remaining compatible with standard IPv6 behavior. In this work, we propose an enhancement to Liu et al.’s model by improving security, latency handling and synchronization forreal-timedeployments.
Alternative strategies have been proposed in various studies. Singh and Bedi [13] proposed a DHCPv6-based dynamicaddressingmethod forsmarthomes,whereIPv6 addressesare periodicallyrenewedaftera fixed duration, reducing static exposure. While this introduces address volatility, it lacks the cryptographic unpredictability seen in fully ephemeral schemes.. Poojary and Manvi [14] proposed a lightweight IPv6 address generation scheme using cryptographic hashes of device ID and shared secrets to achieve address obfuscation and enable secure, dynamic addressing for IoT devices. For severely resource-constrained 6LoWPAN environments, Raza et al. [19] demonstrated that optimized neighbor discovery protocols can reduce header overhead by 40% while maintaining secure address autoconfiguration. The main drawback of this scheme is its reliance on pre-shared secretkeys,whicharedifficulttomanagesecurelyinlarge orfrequentlychangingIoTnetworks.ToufekandBoussaid [15]proposedanephemeralIPv6addressingmethodthat usestheDiffie–Hellmankeyexchangetosecurelyderivea shared secret between devices. This shared secret is then used to generate a unique, temporary IPv6 address for each session. The term ephemeral means short-lived or temporary, helping prevent long-term tracking and reducing the risk of address-based attacks. Aura’s Cryptographically Generated Addresses (CGA) scheme [10] allows devices to create IPv6 addresses tied to a public key, enabling address ownership verification and protection against spoofing. A key drawback of CGA is its computational overhead, which can be too heavy for resource-constrainedIoTdevices.
Recent innovations include blockchain-backed IP assignment for decentralized verification of address legitimacy, as proposed by Abhishek and Chatterjee [16]. While this improves trust and transparency, it introduces notable computational overhead, making it less ideal for low-powerIoTnodes.Alternatively,smartcontract-driven delegation [22] reduces computational overhead by limiting on-chain verification to critical address
International Research Journal of Engineering and Technology (IRJET) e-ISSN:2395-0056
Volume: 12 Issue: 04 | Apr 2025 www.irjet.net p-ISSN:2395-0072
transitions.Inanotherapproach,Boucadairetal.explored IPv6 prefix delegation techniques for efficient address management across IoT clusters [17]. Compared to these models, the scheme in [11] offers a balanced trade-off betweensecurity and implementationsimplicitywithless computational overhead. Our improvements focus on enhancing security using hashing techniques and better synchronization, to make address generation and verification more reliable during client-server communication.
3.EXISTING PROTOTYPE ALGORITHM (BASE PAPER REFERENCE)
ToenhancesecurityinIPv6-basedIoTcommunication,we utilize a dynamic address generation mechanism at the network layer. This mechanism supports both symmetric and asymmetric encryption modes for client-server communication.Thegoalistoeliminatetheneedforstatic server addresses, reducing the risk of address-based attacksandreplayattacks.Thissectiondetailsbothmodes alongwiththeaddressverificationlogicattheserverside.
The implementation follows a prototype architecture and isnotyetdeployed.Itusesprefixdelegation(DHCP-PD) amechanismwhereanIPv6serverassignsasubnetprefix insteadofafullIPaddress,allowingtheclienttogenerate its own IPv6 addresses from this prefix for server-side addressing.Eachgenerated IPv6addressconsists ofa 64bitprefixfromtheserveranda64-bitsuffixgeneratedby the client, forming a complete 128-bit address. Clients generate destination addresses using encrypted identifiers, time-based salts, and cryptographic keys, as proposedbyLiuetal.[11].
3.1 Symmetric Encryption
3.1.1
Client Side
The algorithm generates a dynamic IPv6 destination addressbyfirsthashingtheclient'ssourceaddress(MD5) and combining it with a time-based salt using XOR. This result (P_SA) is then encrypted with DES using a shared keyto produce a 64-bitsuffix.Thesuffix isappendedto a server-assigned prefix (via DHCP-PD) to form the final address. This ensures addresses are time-sensitive and unique, improving security against tracking and replay attacks.
Input:SourceAddress,Key,Prefix,T0,X
Output:DestinationAddress
1. H_SA=md5(SourceAddress)[0:64]
2. T_current=time.currenttime()
3. Salt=(T_current–T0)/X
4. P_SA=XOR(Salt,H_SA)
5. Suffix=DES(P_SA,Key)
6. DestinationAddress=strcat(Prefix,Suffix)
7. returnDestinationAddress
3.1.2
Server Side
This algorithm verifies whether a received IPv6 destination address is valid and timely. The server begins by deriving a 64-bit hash of the client’s source address (H_SA) and extracting the 64-bit suffix from the received destination address. The server iterates through each key in its key pool a collection of possible keys used by clients to decrypt the suffix and retrieve the original padded source address (P_SA), then XORs it with H_SA to retrieve the time-based salt. Using this salt, the server calculates the original time the address was generated (T_send)andcomparesitwiththecurrenttime.Ifthetime difference (T_delta) falls within an acceptable threshold range, the address is considered valid, and the server acceptstherequest;otherwise,itisrejected.
Input: SourceAddress, DestinationAddress, T0, X, T_threshold
Output:True/False
1. H_SA=md5(SourceAddress)[0:64]
2. Suffix=DestinationAddress[64:128]
3. forkeyinkeys():
4. P_SA=DES⁻¹(Suffix,Key)
5. T_current=time.currenttime()
6. Salt=XOR(H_SA,P_SA)
7. T_send=Salt*X+T0
8. T_delta=T_current-T_send
9. ifT_delta<T_thresholdandT_delta>-1*T_threshold:
10. returnTrue
11.returnFalse
3.2 Asymmetric Encryption
3.2.1
Client Side
This algorithm uses RSA encryption instead of symmetric DES.Theclientfirstcreatesahashedversionofitssource address (H_SA) and combines it with a time-based salt to produce P_SA. This value is then encrypted using the client’sprivateRSAkey. Thefirst64 bitsoftheciphertext becomethesuffixoftheIPv6address,whiletheremaining ciphertext forms the payload. The final destination address is constructed by appending this suffix to the 64bitprefixprovidedbytheserver,resultinginafull128-bit IPv6address.
International Research Journal of Engineering and Technology (IRJET) e-ISSN:2395-0056
Volume: 12 Issue: 04 | Apr 2025 www.irjet.net p-ISSN:2395-0072
Input:SourceAddress,PrivateKey,Prefix,T0,X
Output:DestinationAddress,Payload
1. H_SA=md5(SourceAddress)[0:64]
2. T_current=time.currenttime()
3. Salt=(T_current–T0)/X
4. P_SA=XOR(Salt,H_SA)
5. CipherText=RSA(P_SA,PrivateKey)
6. Suffix=CipherText[0:64]
7. Payload=CipherText[64:]
8. DestinationAddress=strcat(Prefix,Suffix)
9. returnDestinationAddress,Payload
3.2.2 Server Side
This algorithm verifies the client's identity and message freshness using asymmetric cryptography. The server hashes the source address (H_SA), extracts the suffix and payload to reconstruct the ciphertext, and decrypts it using the client’s public RSA key to retrieve P_SA. It then derives the salt by XORing P_SA with H_SA, computes the original send time, and checks if the time difference (T_delta) is within an acceptable threshold. If so, the addressisconsideredvalid.
Input: SourceAddress, DestinationAddress, Payload, PublicKey,T0,X,T_threshold
Output:True/False
1. H_SA=md5(SourceAddress)[0:64]
2. Suffix=DestinationAddress[64:128]
3. CipherText=strcat(Suffix,Payload)
4. forkeyinkeys():
5. P_SA=RSA⁻¹(CipherText,PublicKey)
6. T_current=time.currenttime()
7. Salt=XOR(H_SA,P_SA)
8. T_send=Salt*X+T0
9. T_delta=T_current-T_send
10. if T_delta < T_threshold and T_delta > -
1*T_threshold:
11. returnTrue
12.returnFalse
In the symmetric encryption (DES) approach, the encryptedoutputisexactly64bits,whichfitsentirelyinto the suffix of the IPv6 address hence, no additional payloadisneeded.Incontrast,theasymmetricencryption (RSA) method produces a longer ciphertext, so only the
first64bitsareusedasthesuffix,whiletheremainingbits arestoredseparatelyinapayloadfield.
The remaining bits (i.e., the payload) are used during the asymmetric address verification at the server side. Since only the first 64 bits of the RSA ciphertext are embedded in the IPv6 address suffix, the remaining part is transmittedasaseparatepayloadalongwiththerequest.
During verification, the server recombines the suffix and payload to reconstruct the full ciphertext. This complete ciphertext is then decrypted using the public key to recover the padded source address (P_SA). This step is essential for verifying the client's identity and computing thetime-basedsaltusedintheaddressgeneration.
3.3 Compatibility with IPv4
Although the address generation algorithm by Liu et al. [11] is theoretically applicable to IPv4 by assigning a segment of addresses to the server and having clients generate suffixes accordingly it is practically infeasible. The IPv4 address space is extremely limited, making it inefficientandwastefultoreservemultipleaddressesfora singleserver.Moreover,theshortlengthofIPv4addresses significantly weakens the encryption security, as the reduced ciphertext space becomes more susceptible to brute-forceattacks.Consequently,themodelisbestsuited for IPv6, where ample address space and longer suffixes enable both scalability and strong cryptographic protection[11].
3.4 Advantages and Drawbacks
3.4.1
Advantages
1) Dynamic Address Confidentiality: By generating server destination addresses using encryption and time-based values, the algorithm hides server identity, reducing exposuretoscanningandDDoSattacks.
2) Replay Attack Resistance: Time-based salts introduce freshness in each generated address, making it harder for adversariestoreuseinterceptedpackets.
3)Encryption Flexibility: Supportfor both symmetric and asymmetric encryption allows the mechanism to adapt to theresourceconstraintsofdifferentIoTdevices.
4) Address Scalability via Prefix Delegation: The use of DHCPv6 Prefix Delegation allows servers to manage a range of addresses, enabling scalable deployment across multiple devices and services without requiring a fixed addressperserver.
3.4.2
Disadvantages
1)WeaknessofXOROperation:TheuseofsimpleXORfor mixing time-based salts and hashed identifiers may not
International Research Journal of Engineering and Technology (IRJET) e-ISSN:2395-0056
Volume: 12 Issue: 04 | Apr 2025 www.irjet.net p-ISSN:2395-0072
provide strong diffusion, making it vulnerable to cryptanalysis thiscanbeimprovedbyusingsecurehashbasedmixing.
2) Lack of Mutual Key Agreement: The symmetric mode relies on pre-shared keys without session-specific negotiation. Incorporating a key exchange protocol like Diffie–Hellmancanprovidebettersession-levelsecrecy.
3) Rigid Time Synchronization: The algorithm heavily depends on synchronized clocks for address validation. A more secure approach could involve nonce-based freshness or combined verification to handle network delaysandclockdrift.
4) Payload Overhead in Asymmetric Mode: In the asymmetricencryptionvariant,aportionoftheciphertext is embedded in the payload for address validation, increasing packet size and potentially affecting performance in low-bandwidth or latency-sensitive IoT networks.
4. PROPOSED IMPROVEMENTS TO ENHANCE THE ALGORITHM
4.1 Improvements
4.1.1 Replacing XOR with HMAC-Based Transformation
In the original symmetric encryption-based model, the client generates a temporary IPv6 address suffix by XORing a time-based Salt with a hash of the source address. This transformation helps ensure the dynamic generation of destination addresses, which are later encrypted with a symmetric key (e.g., using DES). However,thismethodpresentsanotablesecurityconcern duetothereversiblenatureofXOR.
ClientSide:
1. H_SA=md5(SourceAddress)[0:64]
2. T_current=time.currenttime()
3. Salt=(T_current–T0)/X
4. P_SA=XOR(Salt,H_SA)
5. Suffix=DES(P_SA,Key)
ServerSide:
1. H_SA=md5(SourceAddress)[0:64]
2. Suffix=DestnAddress[64:128]
3. forkeyinkeys():
4. P_SA=DES⁻¹(Suffix,Key)
5. T_current=time.currenttime()
6. Salt=XOR(H_SA,P_SA)
7. T_send=Salt*X+T0
Ontheserverside,thesuffixisdecryptedtorecoverP_SA, and the Salt is recalculated by XORing it again with the hash.However,XOR’ssimplicitybecomesitsweakness.
ForExample:
LetSalt=1100,H_SA=1011
Atclientside: P_SA=XOR(Salt,H_SA)=0111
Attacker can find P_SA if he intercepts the traffic to find thedestinationaddressandsomehowmanagestofindthe key.
P_SA=decrypt(suffixofdestnaddress,key)
The attacker can know or guess H_SA (e.g., through dictionaryattacksoncommonIPs,bruteforceattack) So,AttackerhasH_SA=1011,P_SA=0111 Salt=XOR(H_SA,P_SA)=1100
Possibleattacksare:
1) Spoofing: This salt can be used to generate valid IPv6addresses.Theseaddresseswillthenbeused forspoofing.
2) Replay Attack: It can also lead to replay attack where the attacker will impersonate the client andsendpacketstotheserver.Itispossibleifthis Dynamically assigned server address remains valid for a short period of time. Within this time, theattackerhastoperformthereplyattack.
To mitigate this risk, we replace XOR with HMAC, which provides cryptographic integrity and prevents attackers fromextractingSalt.Therevisedimplementationuses: Client-SideComputation:
1.H_SA=md5(SourceAddress)[:64]
2.Salt=(T_current-T0)/X
3.P_SA=HMAC(Salt,H_SA,Key)
4.Suffix=DES(P_SA,Key)
Fig -1: ProposedImprovements
International Research Journal of Engineering and Technology (IRJET) e-ISSN:2395-0056
Volume: 12 Issue: 04 | Apr 2025 www.irjet.net p-ISSN:2395-0072
Server-SideVerification:
1.ExtractSuffix
2.ComputeP_SA=DES⁻¹(Suffix,Key)
3.ComputeSalt=HMAC(P_SA,H_SA,Key)
4.ValidateT_delta
Thus, to enhance security, the reversible XOR operation used for combining the Salt and hashed source address was replaced with HMAC, a one-way keyed hashing function.Thisensuresthatevenifintermediatevaluesare intercepted, the Salt cannot be recovered or tampered with.
AdvantagesofusingHMACoverXOR:
1) Irreversibility: HMAC prevents attackers from recoveringSaltevenifothervaluesareknown.
2) Replay Protection: Time-based input in HMAC resistsreuseofoldaddresssuffixes.
3) Tamper Resistance: Small changes in input yield completelydifferentoutputs,preventingforgery.
4) Efficiency: HMAC introduces minimal computational overhead, making it suitable for real-timeuse.
4.1.2 Using Diffie–Hellman Key Exchange Instead of Static Shared Keys
The following line in Section VI. A. 2) point of the base paperindicatesthatthekeybeingusedisafixedkey:“The authenticated client and the server save the key pair. The client uses the algorithm described in this paper to generatea destinationaddressincommunication,andthe server performs verification by the addresses.” as statedinLiuetal.[11].
The use of a static key for every communication introduces a significant vulnerability. If an attacker interceptsenoughdata over time,theymaybreak thekey using brute force or cryptanalysis. Even with the replacement of XOR by HMAC, a fixed key remains a weakness, as it does not provide forward secrecy. If the key is ever compromised, all past and future communications using that key are at risk, making the system susceptible to replay attacks and unauthorized access.
As a proposed improvement, we suggest using DiffieHellman (DH) key exchange for dynamic key rotation.The Diffie-Hellman (DH)] key exchange is a cryptographic protocol that allows two parties to establish a shared secret over an insecure communication channel. It is widely used in secure communication protocols such as TLSandVPNs.
Here is the working principle of Diffie Hellman key exchange. We need two publicly known parameters: a
large prime number p, a primitive root g (generator) modulop.
KeyExchangeSteps:
1) The client selectsa private keya and computes A =g^amodp.
2) TheserverselectsaprivatekeybandcomputesB =g^bmodp.
3) BothexchangetheirpublicvaluesAandB.
4) ThesharedsecretiscomputedasS=B^amodp= A^bmodp.
Since an attacker only sees A and B, they cannot derive S without solving the discrete logarithm problem, which is computationallyhard.
PublicParameters:p(prime),g(generator)
Client:
1.a=random() #Clientprivatekey
2.A=g^amodp #Clientpublickey
Server:
1.b=random() #Serverprivatekey
2.B=g^bmodp #Serverpublickey
ExchangeAandB
SharedKey:
1.Clientcomputes:K=B^amodp
2.Servercomputes:K=A^bmodp
Theclientandserverexchangepublickeys(AandB),then each computes the same shared key K using their private key and the other's public key. This key is never transmitted,makingitsecureagainsteavesdropping.
Diffie-Hellmanisusedinsymmetricencryptiontosecurely generateasharedsecretkeybetweentwoparties.Itisnot used in asymmetric encryption, as it doesn't produce public/privatekeypairslikeRSAorECC.
Advantages:
1) Dynamic Keys for Better Security: A new key is generatedeachsession,preventingkeyreuseand futuredecryptionbyattackers.
2) Replay&BruteForceProtection:Time-basedkeys make old messages invalid, blocking replay and brute-forceattacks.
3) Defense Against Cryptanalysis: Changing keys prevent patterns across messages, reducing the riskofkeydeduction.
4) Partial Mitigation of MitM Attacks: Prevents passiveinterception,though activeMitMrequires additionalauthentication.
International Research Journal of Engineering and Technology (IRJET) e-ISSN:2395-0056
Volume: 12 Issue: 04 | Apr 2025 www.irjet.net p-ISSN:2395-0072
4.1.3 Enhancing Time-Only Salt with HMAC-Based Nonce
InSectionVI.A.1)ofthebasepaper,theclientgeneratesa destinationaddressusingatime-basedsaltcombinedwith an XOR operation over a hashed source address and the salt. The server verifies the address by reversing the XOR and checking whether the resulting time lies within an allowedthreshold.
Thisapproach,whileefficient,hasacriticallimitation it relies purely on time as entropy. A deterministic address generationmechanismusingonlytime-basedsaltandXOR lacksstrongrandomnessandcanbepredictedorreplayed if an attacker can estimate or sniff the time window. Furthermore, XOR and MD5 do not offer sufficient cryptographicresistanceagainstmodernthreats.
Toimprovebothsecurityandresistancetoreplayattacks, weproposetheintegrationofHMAC-basednonces.HMAC (Hash-based Message Authentication Code) introduces a keyed hash function that binds the nonce to both the key and the expiry time, providing a much stronger cryptographicfoundationthansimpleXOR.
WeintroducetwoHMAC-basedschemes:
1) StatefulNoncewithServer-SideTracking
2) StatelessNoncewithExpiryTimestamp
Each approach combines time-awareness with cryptographicintegrity.
1)StatefulHMACNoncewithServer-SideTracking WorkingPrinciple:
1) TheclientcomputesanonceusingHMACoverthe currenttimeandsourceaddress.
2) The server decrypts and checks whether the noncehasalreadybeenused.
3) If the nonce is seen for the first time, the request isvalidandthenonceisstored.
4) Subsequent use of the same nonce is rejected, thuspreventingreplay.
Advantages:
1) HMACenhancessecuritybyresistingcollisionand pre-imageattacks,unlikeMD5orXOR.
2) It ties the nonce to both a secret key and a timestamp,improvingdataintegrity.
3) Replay protection is achieved through two variants: the stateless variant uses expiry to invalidateoldaddresses,whilethestatefulvariant tracksandblocksreusednonces.
4) Forwardsecrecyismaintainedusingtime-varying nonces, which reduce predictability and pattern leakage.
5) Cryptographic strength is improved by eliminating weak hash functions like MD5 and
XOR, and adopting the robust HMAC with SHA256.
Disadvantages:
1) Storage Overhead: Theservermuststoreeachusednonce,leadingto increased memory usage that can grow significantlyinhigh-trafficenvironments.
2) Scalability Constraints: As the number of IoT devices increases, maintaining and searching through large nonce recordscandegradeperformance.
3) Maintenance Complexity: Requires mechanisms to purge expired or old noncesperiodically,addingtosystemcomplexity.
4) LatencyRisk:
Validating each nonce against a stored list may introduce delays in systems with high request volumes.
2)StatelessHMACNoncewithExpiryTimestamp
WorkingPrinciple:
1) Theclientcomputesafutureexpirytimestamp.
2) An HMAC is generated using the key and the combinationofthesourceaddressandtheexpiry timestamp.
3) This nonce is then encrypted and attached to the prefixtoformthedestinationaddress.
4) The server, upon receiving the address, decrypts the nonce and checks it against possible expiry valueswithinanalloweddrift.
Advantages:
1) No server-side memory required for tracking state.
2) Preventsreplaywithintheallowedtimewindow.
3) Offers expiry-based validation beyond simple timestamps.
Disadvantages:
1) Limited Replay Protection: Since validation is based only on the timestamp, an attacker can reuse a captured address within theallowedexpirywindow.
2) Dependence on Time Synchronization: Requiresprecisetimesync(e.g.,viaNTP)between client and server. Any clock drift can lead to false rejectionsorsecuritygaps.
3) No Usage Tracking: Without server-side state, it cannot detect repeated use of a valid (but old) nonce within its validtimeframe.
4) Short Lifetime Trade-off: Tighter expiry reduces replay risk but increases the chances of legitimate packet rejection due to minordelays.
International Research Journal of Engineering and Technology (IRJET) e-ISSN:2395-0056
Volume: 12 Issue: 04 | Apr 2025 www.irjet.net p-ISSN:2395-0072
Steps:
Client:
1.T_expiry=T_current+T_lifetime
2.nonce=HMAC(key,source_address+T_expiry)
3.encrypted_nonce=DES_Encrypt(nonce,key)
4.destination_address=prefix+encrypted_nonce
Server:
In the original model, once the server verified the structure of the dynamically generated IPv6 address (i.e., confirming that the suffix was correctly derived from the client’shashedsourceaddressandthe time-basedsalt),it implicitly trusted the authenticity of the client. However, thiscreatesasignificantsecuritygap.
If an attacker successfully reconstructs a valid address suffix using intercepted or guessed components, they can impersonate a legitimate client. Without an explicit authentication mechanism, server-side validation alone is insufficient to prove the sender’s identity or message integrity. To overcome this, we integrate Digital Signatures cryptographic methods that guarantee data authenticityandintegrityusingaprivatekeytosignanda public/sharedkeytoverify.
Symmetric System: HMAC-Based Digital Signatures
In the improved symmetric model, a shared key (established via Diffie-Hellman) is used not only for address encryption but also for signing the final destination IPv6 address using an HMAC-based digital signature:
ClientSide:
AftergeneratingthefulldestinationIPv6address(Prefix+ EncryptedSuffix),theclientcomputes: signature = HMAC(shared_key, destination_address) Thissignatureissentalongwiththedestinationaddress.
ServerSide:
After independently regenerating the destination address from the client’s information, the server verifies the signature:
1. expected_signature = HMAC(shared_key, destination_address)
2.ifexpected_signature==received_signature: accept else: reject
Advantages:
1) Mutual Trust: Server no longer assumes authenticitybasedonlyonaddressstructure.
2) Replay Defense: Even if a valid suffix is reused, it must be re-signed with the correct shared key,
1.decrypted_nonce=DES_Decrypt(suffix,key) 2.Fortin[T_current±drift]: If HMAC(key, source_address + t) == decrypted_nonce: Accept
4.1.4 Employing Digital Signatures Instead of Implicit Trust for Authentication
and the freshness is enforced through time validation.
3) Tamper Protection: Any modification to the address or its suffix will lead to signature mismatch.
Asymmetric System: RSA-Based Digital Signatures
For scenarios involving multiple clients or where publicprivate key infrastructure (PKI) is preferred, asymmetric digitalsignaturesprovidestrongertrustseparation.
ClientSide:
The client generates the address suffix using HMAC + nonce logic, encrypts it with the server’s RSA public key, and signs the resulting IPv6 address using its own RSA privatekey:
signature=RSA_sign(private_key,destination_address)
ServerSide:
The server uses the client's public key (previously exchangedorregistered)toverifythesignature:
valid = RSA_verify(public_key, destination_address, received_signature)
Advantages:
1) Decentralized Trust: Each client has a unique private key; even if one is compromised, others remainunaffected.
2) Non-repudiation: Clients cannot deny address generation since their private key uniquely signs it.
3) Security Compliance: RSA signatures are widely accepted in secure communications (e.g., TLS, PGP).
4.1.5 Replacing Static Drift Handling with NTPAware Adaptive Thresholding Mechanism for Time Synchronization
This method represents an improved and adaptive approach to managing the secure communication of an addressless IoT server by dynamically generating IPv6 addresses based on synchronized time and real-time network conditions. The key objective is to eliminate legitimate packet drops due to minor network delays,
© 2025, IRJET | Impact Factor value: 8.315 | ISO 9001:2008 Certified Journal | Page1323
International Research Journal of Engineering and Technology (IRJET) e-ISSN:2395-0056
Volume: 12 Issue: 04 | Apr 2025 www.irjet.net
jitter, or client-server clock mismatches, all while maintainingstrongcryptographicintegrity.
To begin with, the system establishes time synchronization using the Network Time Protocol (NTP) byqueryingpool.ntp.org.Thisensuresboththeclientand server share a consistent time reference. If NTP synchronization fails, the system defaults to the local system time. Time synchronization is essential for determining the validity of dynamically generated IPv6 addresses,whicharetiedtospecifictimewindows.
To further improve reliability, the code introduces an AdaptiveThreshold class that calculates a flexible, realtimewindowoftoleranceforpacketdelays.Thisclassuses an exponentially weighted moving average (EWMA) to adjustitsthresholddynamically.Eachtimeanewnetwork delay measurement is observed, it updates the dynamic threshold using a smoothing factor (alpha), keeping it between 30s and 120s. This ensures that the system can reacttofluctuatinglatencywithoutcompromisingsecurity orusability.
Once the system has a reliable time and adaptive threshold, it generates IPv6 suffixes using AES-256 encryption.Thesuffixisderivedfromacombinationofthe client’s IP address, the current timestamp (plus or minus 30 and 60 seconds), and a shared session key. The pad() function ensures proper block length for encryption by applying PKCS-style padding. The resulting ciphertext is encoded using Base64 and trimmed to 16 characters, formingthedynamicsuffixoftheIPv6address.Thissuffix is then prefixed with a fixed IPv6 prefix (2001:db8::) to formafulladdress.
Because the suffix generation uses both cryptographic security and time-window flexibility, a packet can arrive slightlyearlierorlaterthanexpectedandstillbevalidated successfully, preventing legitimate packet loss due to minortimingdifferences.
Steps:
1.initialize(base_threshold=30,alpha=0.3):
setdynamic_threshold=base_threshold setalpha=smoothingfactor(e.g.,0.3)
2.methodupdate_threshold(network_delay): dynamic_threshold = (alpha × network_delay) + ((1alpha)×dynamic_threshold) clampdynamic_thresholdtostaybetween30and120 returndynamic_threshold
Advantages:
1) Accurate Time Synchronization: Ensures client andserverclocksarealignedusingNTP,reducing packetrejection.
p-ISSN:2395-0072
2) Reduced Packet Loss: Multi-window verification (±60s) accepts slightly delayed packets, improvingreliability.
3) Dynamic Threshold Adaptation: Automatically adjusts to real-time network delays, maintaining balancebetweensecurityandusability.
4) Stronger Encryption: Uses AES-256 instead of DES, making IPv6 address suffixes cryptographicallysecure.
5) Replay Attack Protection: Each address is timebound and changes frequently, preventing reuse byattackers.
6) Improved Usability: Fewer dropped packets and smoother communication improve user experiencewithoutcompromisingsecurity.
4.2 PROPOSED ALGORITHM
1. Symmetric Key-Based IPv6 Address Generation –Client Side
Input: Source Address (SAh), Sared Symmetric Key (K), Prefix (P), Epoch Start Time (T₀)
Output: Destination IPv6 Address (DA), HMAC-based Signature(SIG)
Fig -2: DynamicAddressGenerationbyClient
Fig -3: DynamicAddressValidationbyServer
International Research Journal of Engineering and Technology (IRJET) e-ISSN:2395-0056
Volume: 12 Issue: 04 | Apr 2025 www.irjet.net p-ISSN:2395-0072
1. GetsynchronizedtimeT_currentfromNTP.
2. ComputeSalt=(T_current−T₀)//X.
3. GenerateH(SA)=MD5(SA).
4. Computenonce=HMAC(K,SA+Salt).
5. Derive P_SA = First 4 bytes of HMAC(K, H(SA) + nonce).
6. Concatenate:suffix_data=P_SA||nonce.
7. Encrypt:suffix=DES_K(suffix_data).
8. Formdestinationaddress:DA=P||suffix.
9. Signaddress:SIG=HMAC(K,DA).
10. Transmit⟨DA,SIG⟩toserver.
2. Symmetric Key-Based Address Verification – Server Side
Input: Source Address (SA), Destination Address (DA), SharedKey(K),EpochStartTime(T₀),AdaptiveThreshold Δt
Output: Boolean(Trueifvalid,elseFalse)
1. ExtractencryptedsuffixfromDA.
2. DecryptusingDES_K:GetP_SA’andnonce’.
3. GetcurrenttimeT_nowfromNTP.
4. ComputeSalt_now=(T_now−T₀)//X.
5. Fordrift∈[−Δt//X,+Δt//X]:
○ ReconstructSalt_try=Salt_now+drift.
○ Computeexpectednonce=HMAC(K,SA+ Salt_try).
○ ReconstructexpectedP_SA=First4bytes ofHMAC(K,H(SA)+expectednonce).
○ IfP_SA’==expectedP_SA→Valid.
6. Verifysignature:SIG'=HMAC(K,DA).
7. ReturnTrueif bothaddress andsignaturematch; elseFalse.
3. Asymmetric Key-Based IPv6 Address Generation –Client Side
Input: Source Address (SA), RSA Public Key (PK), Prefix (P), Epoch Start Time (T₀), Private Signing Key (SK) Output: Destination IPv6 Address (DA), Payload, Digital Signature(SIG)
1. GetcurrentNTPtimeT_current.
2. ComputeSalt=(T_current−T₀)//X.
3. GenerateH(SA)=MD5(SA).
4. Computenonce=HMAC(H(SA),SA+Salt).
5. DeriveP_SA=HMAC(H(SA),H(SA)+nonce).
6. Formpayload_data=P_SA||nonce.
7. Encrypt with RSA: cipher = RSA_PK(payload_data).
8. Extract:suffix=First16hexcharsofcipher.
9. Compute DA = P || suffix; Payload = Remaining cipher.
10. Sign:SIG=RSA_SK(DA).
11. Transmit⟨DA,Payload,SIG⟩toserver.
4. Asymmetric Key-Based Address Verification –Server Side
Input: Source Address (SA), Destination Address (DA), Payload, RSA Private Key (SK), Epoch Start Time (T₀), Adaptive Threshold Δt Output: Boolean(Trueifvalid,elseFalse)
1. Reconstructfullcipher=DA_suffix||Payload.
2. Decrypt:payload_data=RSA_SK(cipher).
3. ExtractP_SA’andnonce’frompayload_data.
4. GetcurrenttimeT_nowfromNTP.
5. ComputeSalt_now=(T_now−T₀)//X.
6. Fordrift∈[−Δt//X,+Δt//X]:
○ Generate expected nonce = HMAC(H(SA), SA+Salt_try).
○ Compute expected P_SA = HMAC(H(SA), H(SA)+expectednonce).
○ IfP_SA’==expectedP_SA→Valid.
7. VerifysignatureSIGusingRSA_PK.
8. Return True if both address and signature are valid;elseFalse.
Fig -4: BlockDiagramofProposedSolution
5. CONCLUSIONS AND FUTURE SCOPE
5.1 Conclusion
This paper presented an enhanced dynamic IPv6 addressing scheme for secure IoT communication that buildsupontheaddresslessservermodelproposedbyLiu
International Research Journal of Engineering and Technology (IRJET) e-ISSN:2395-0056
Volume: 12 Issue: 04 | Apr 2025 www.irjet.net p-ISSN:2395-0072
et al. [11]. Our improvements address critical vulnerabilitiesintheoriginalapproach,including:
1) Cryptographic Weaknesses: Replacing XOR with HMACtopreventsaltrecoveryattacks.
2) Key Management: Introducing Diffie-Hellman key exchange for dynamic session keys, eliminating statickeyvulnerabilities.
3) Time Synchronization: Implementing NTP-aware adaptive thresholds to reduce false rejections whilemaintainingsecurity.
4) Authentication: Adding digital signatures (HMAC/RSA)toverifyclientidentityexplicitly.
5) ReplayAttack Resistance: Usingstateful/stateless HMACnoncestoenhanceaddressuniqueness.
Experimental validation (to be conducted in future work) will measurethe trade-offs betweensecurity,latency,and scalability in real-world IoT deployments. Preliminary analysis suggests that the proposed enhancements maintain compatibility with standard IPv6 while significantly improving resistance to scanning, spoofing, andDDoSattacks.
5.2 Future Scope
1) Lightweight Cryptography: Investigate postquantum cryptographic algorithms (e.g., CRYSTALS-Kyber) for resource-constrained IoT devices.OptimizeHMAC-SHA256foredgedevices withhardwareacceleration.
2) Decentralized Key Management: Explore blockchain-based key distribution to enhance trustinlarge-scaleIoTnetworks[22].
3) Machine Learning for Anomaly Detection: Integrate LSTM-based traffic analysis [21] to detectmaliciousaddressgenerationpatterns.
4) Standardization Efforts: Propose an IETF RFC for dynamic IPv6 addressing in IoT, building on DHCPv6andSLAAC.
5) 6LoWPAN Optimization: Adapt the scheme for constrained networks using header compression techniques[19].
6) Edge Computing Integration: Test fog-assisted address delegation [20] to reduce latency in industrialIoTscenarios.
Byaddressing these directions,the proposedsolution can evolve into a robust framework for secure, scalable, and efficientIoTcommunicationintheIPv6era.
5.3 Key Contributions Summary
Aspect Base Model [11] Our Improvements
SaltGeneration XOR(reversible) HMAC(irreversible)
KeyExchange Statickeys Diffie-Hellman
Authentication Implicit (addressbased) Digitalsignatures
TimeHandling Fixedthreshold NTP+adaptive
ReplayProtection Time-only HMAC-basednonces
Table -1: Key Contributions
ACKNOWLEDGEMENT
This work is supported in part by Prof. Varshapriya Jyotinagar. We thank the reviewers for their valuable discussionsandfeedback.
REFERENCES
[1] S.DeeringandR.Hinden,"InternetProtocol,Version6 (IPv6)Specification,"RFC8200,IETF,2017.
[2] A. Whitmore, A. Agarwal, and L. Da Xu, "The Internet of Things A survey of topics and trends," InformationSystemsFrontiers,vol.17,no.2,pp.261–274,2015.
[3] S.Sicari,A.Rizzardi,L.A.Grieco,andA.Coen-Porisini, "Security, privacyand trust inInternet of Things:The road ahead," Computer Networks, vol. 76, pp. 146–164,2015.
[4] A. Alrawais, A. Alhothaily, C. Hu, and X. Cheng, "Fog computing for the Internet of Things: Security and privacy issues," IEEE Internet Computing, vol. 21, no. 2,pp.34–42,2017.
[5] H. Ning and H. Liu, "Cyber-physical-social based security architecture for future Internet of Things," Advances in Internet of Things, vol. 2, no. 1, pp. 1–7, 2012.
[6] Y.Huangetal.,"Anaddresslessservermodelbasedon IPv6forsecureIoTcommunication,"IEEEAccess,vol. 10,pp.84934–84945,2022.
[7] A. Atamli and A. Martin, “Threat-based security analysis for the Internet of Things,” 2014 International Workshop on Secure Internet of Things (SIoT),pp.35–43.
International Research Journal of Engineering and Technology (IRJET) e-ISSN:2395-0056
Volume: 12 Issue: 04 | Apr 2025 www.irjet.net p-ISSN:2395-0072
[8] R. Roman, P. Najera, and J. Lopez, “Securing the Internet of Things,” Computer, vol. 44, no. 9, pp. 51–58,2011.
[9] S. Sicari et al., “Security, privacy and trust in Internet of Things: The road ahead,” Computer Networks, vol. 76,pp.146–164,2015.
[10] [T. Aura, “Cryptographically Generated Addresses (CGA),”RFC3972,IETF,Mar.2005.[Online].Available: https://www.rfc-editor.org/info/rfc3972
[11] R. Liu et al., “Addressless: Enhancing IoT Server SecurityUsing IPv6,” IEEE Access,vol.8,pp. 182556–182567, 2020. BASE PAPER[Online]. Available: https://doi.org/10.1109/ACCESS.2020.3028910
[12] Z.Shelbyetal.,“TheConstrainedApplicationProtocol (CoAP),” RFC 7252, IETF, Jun. 2014.[Online]. Available:https://www.rfc-editor.org/info/rfc7252
[13] K. Singh and H. Bedi, “Dynamic Addressing in IPv6Based Smart Homes Using DHCPv6,” International Journal of Computer Applications, vol. 174, no. 8, pp. 1–6, Sept. 2017.[Online]. Available: https://doi.org/10.5120/ijca2017914886
[14] S.PoojaryandS.S.Manvi,“ASecureandDynamicIPv6 AddressAllocationSchemeforIoTNetworks,”inProc. 2020 Intl. Conf. on Smart Technologies in Computing, ElectricalandElectronics(ICSTCEE),Bengaluru,India, Oct. 2020, pp. 386–391.[Online]. Available: https://doi.org/10.1109/ICSTCEE49637.2020.92771 41
[15] A.ToufekandL.Boussaid,“ASecureIPv6Addressing Scheme Using Diffie–Hellman Key Exchange for IoT,” in Proc. 2020 Intl. Conf. on Advanced Communication TechnologiesandNetworking(CommNet),Marrakech, Morocco, Sep. 2020, pp. 1–6.[Online]. Available: https://doi.org/10.1109/CommNet49926.2020.9199 76
[16] A. Abhishek and A. Chatterjee, “Blockchain-based Dynamic IP Address Management in IoT Networks,” International Journal of Communication Systems, vol. 34, no. 17, pp. 1–14, 2021.[Online]. Available: https://doi.org/10.1002/dac.4935
[17] M.Boucadair,C.Jacquenet,andA.Noveck,“IPv6Prefix Delegation for IoT Devices,” IEEE Communications Magazine, vol. 56, no. 2, pp. 148–154, Feb. 2018.[Online].Available:https://doi.org/10.1109/MC OM.2018.1700383
[18] K. ElDefrawy et al., "Lightweight and Secure IPv6 Addressing for IoT Devices Using Physically Unclonable Functions," IEEE Internet of Things
Journal, vol. 7, no. 1, pp.420–432,2020,Available:10.1109/JIOT.2019.2947465
[19] S. Raza et al., "Secure IPv6 Communication in Constrained IoT Networks Using 6LoWPAN", IEEE InternetofThingsJournal,vol.6,no.1,pp.1150-1162, 2019,Available:10.1109/JIOT.2018.2867491
[20] L. Wang et al., "Edge-Assisted Dynamic IPv6 Addressing for DDoS-Resilient IoT Networks", IEEE Transactions on Industrial Informatics, vol. 17, no. 3, pp. 2029-2041, 2021, Available: 10.1109/TII.2020.2991673
[21] A. Al-Hawawreh et al., "LSTM-Based Anomaly Detection for Malicious IPv6 Traffic in IoT Environments", IEEE Sensors Journal, vol. 22, no. 5, pp. 4451-4463, 2022, Available:: 10.1109/JSEN.2021.3136754
[22] L. Zhang et al., "Decentralized IPv6 Address Management for IoT Using Smart Contracts," IEEE Transactions on Industrial Informatics, vol. 18, no. 6, pp. 4061–4070, 2022, Available: 10.1109/TII.2021.3119202