]> Fastly Inc.

fde@00f.net

Internet-Draft IP addresses are personally identifiable information that requires protection, yet common techniques such as truncation destroy data irreversibly while providing inconsistent privacy guarantees, and ad-hoc encryption schemes often lack interoperability and security analysis. This document specifies secure, efficient methods for encrypting IP addresses for privacy-preserving storage, logging, and analytics, addressing data minimization concerns raised in . Four concrete instantiations are defined: ipcrypt-deterministic provides deterministic, format-preserving encryption with 16-byte outputs; ipcrypt-pfx provides deterministic, prefix-preserving encryption that maintains network relationships with native address sizes (4 bytes for IPv4, 16 bytes for IPv6); while ipcrypt-nd and ipcrypt-ndx introduce randomness to prevent correlation. All methods are reversible with the encryption key and designed for high-performance processing at network speeds. Discussion Venues Source for this draft and an issue tracker can be found at .

Introduction IP addresses are personally identifiable information requiring protection, yet common anonymization approaches have fundamental limitations. Truncation (zeroing parts of addresses) irreversibly destroys data while providing variable privacy levels; A /24 mask may obscure one user or thousands depending on network allocation. Hashing produces non-reversible outputs unsuitable for operational tasks such as abuse investigation. Ad-hoc encryption schemes often lack rigorous security analysis and have limited interoperability. This document addresses these deficiencies by specifying secure, efficient, and interoperable methods for IP address encryption and obfuscation. This specification addresses concerns raised in regarding confidentiality when sharing data with third parties. Unlike existing practices that obscure addresses, these methods provide mathematically provable security properties, which are discussed throughout this document and summarized in .

Use Cases and Motivations Organizations handling IP addresses require mechanisms to protect user privacy while maintaining operational capabilities. Generic encryption systems expand data unpredictably, lack compatibility with network tools, and are not designed for high-volume processing. The specialized methods in this specification address these requirements:

• Efficiency and Compactness: All variants operate on 128 bits, achieving single-block encryption speed required for network-rate processing. Non-deterministic variants add only 8-16 bytes of tweak overhead.
• High Usage Limits: Non-deterministic variants safely handle massive volumes: approximately 4 billion operations for ipcrypt-nd and 18 quintillion for ipcrypt-ndx per key, without degrading security. Generic encryption often requires complex key rotation schemes at lower thresholds.
• Format Preservation: The ipcrypt-deterministic and ipcrypt-pfx variants produce valid IP addresses rather than arbitrary ciphertext, enabling encrypted addresses to pass through existing network infrastructure, monitoring tools, and databases without modification. The ipcrypt-pfx variant uniquely preserves network prefix relationships while maintaining the original address type and size, enabling network-level analytics while protecting individual address identity (see ).
• Interoperability: All conforming implementations produce identical results, enabling data exchange between different systems, vendors, and programming languages.

These specialized encryption methods enable several use cases:

• Privacy Protection: Prevents exposure of sensitive user information to third parties in logs, analytics data, and network measurements (). The key holder retains decryption capability.
• Correlation Attack Resistance: Non-deterministic variants leverage random tweaks to hide patterns and enhance confidentiality (see ).
• Privacy-Preserving Analytics: Encrypted IP addresses can be used directly for counting unique clients, rate limiting, or deduplication without revealing original values. This addresses the anonymization requirements for DNS query data sharing outlined in . The ipcrypt-pfx variant preserves network prefixes for network-level analytics, while other methods scramble network hierarchy.
• Third-Party Integration: Encrypted IP addresses can serve as privacy-preserving identifiers when interacting with untrusted services, cloud providers, or external platforms.

The following examples demonstrate how the same IP addresses transform under each method:

• Format-preserving: Valid IP addresses, same input always produces same output:

d1e9:518:d5bc:4487:51c6:c51f:44ed:e9f6 192.168.1.254 -> fd7e:f70f:44d7:cdb2:2992:95a1:e692:7696 192.168.1.254 -> fd7e:f70f:44d7:cdb2:2992:95a1:e692:7696 # Same output ]]>

• Prefix-preserving: Maintains network structure, same prefix when IPs share prefix:

251.81.131.124 192.168.1.254 -> 251.81.131.159 # Prefix is preserved 172.16.69.42 -> 165.228.146.177 ]]>

• Non-deterministic: Larger output, different each time:

f0ea0bbd...03aa9fcb 192.168.1.254 -> 620b58d8...2ff8086f 192.168.1.254 -> 35fc2338...25abed5d # Same input, different outputs ]]> For implementation guidelines, see .

Relationship to IETF Work This section is to be removed before publishing as an RFC. This document does not conflict with active IETF working group efforts. While the IETF has produced several RFCs related to privacy (, , ), there is no current standardization effort for IP address encryption methods. This specification complements existing IETF privacy guidance by providing implementation methods. The cryptographic primitives used (AES, format-preserving encryption) align with IETF cryptographic recommendations, and the document follows IETF formatting and terminology conventions where applicable.

Terminology The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. Throughout this document, the following terms and conventions apply:

• IP Address: An IPv4 or IPv6 address as defined in .
• IPv4-mapped IPv6 Address: An IPv6 address format (::ffff:a.b.c.d) used to represent IPv4 addresses within the IPv6 address space, enabling uniform processing of both address types.
• 16-Byte Representation: A fixed-length representation used for both IPv4 (via IPv4-mapped IPv6) and IPv6 addresses.
• Block Cipher: A deterministic cryptographic algorithm that encrypts fixed-size blocks of data (128 bits in this specification) using a secret key.
• Permutation: A bijective function where each distinct input maps to a unique output, ensuring reversibility.
• Pseudorandom Function (PRF): A deterministic function that produces output computationally indistinguishable from truly random values.
• Tweakable Block Cipher (TBC): A block cipher that accepts an additional non-secret parameter (tweak) along with the key and plaintext, allowing domain separation without changing keys.
• Tweak: A non-secret, additional input to a tweakable block cipher that further randomizes the output.
• Deterministic Encryption: Encryption that always produces the same ciphertext for a given input and key.
• Non-Deterministic Encryption: Encryption that produces different ciphertexts for the same input due to the inclusion of a randomly sampled tweak.
• Prefix-Preserving Encryption: An encryption mode where IP addresses from the same network produce ciphertexts that share a common encrypted prefix, maintaining network relationships while obscuring actual network identities.
• Birthday Bound: The point at which collisions become statistically likely in a random sampling process, approximately 2^(n/2) operations for n-bit values.
• (Input, Tweak) Collision: A scenario where the same input is encrypted with the same tweak. This reveals that the input was repeated but not the input’s value.

IP Address Conversion This section describes the conversion of IP addresses to and from a 16-byte representation used by ipcrypt-deterministic, ipcrypt-nd, and ipcrypt-ndx. The ipcrypt-pfx method differs by maintaining native address sizes—4 bytes for IPv4 and 16 bytes for IPv6—to preserve network structure (see ).

Converting to a 16-Byte Representation

IPv6 Addresses IPv6 addresses (128 bits) are converted directly using network byte order as specified in . Example:

IPv4 Addresses IPv4 addresses (32 bits) are mapped using the IPv4-mapped IPv6 format as specified in :

Converting from a 16-Byte Representation to an IP Address Conversion algorithm:

1. Examine the first 12 bytes of the 16-byte representation
2. If they match the IPv4-mapped prefix (10 bytes of 0x00 followed by 0xFF, 0xFF):
   • Interpret the last 4 bytes as an IPv4 address in dotted-decimal notation
3. Otherwise:
   • Interpret the 16 bytes as an IPv6 address in colon-hexadecimal notation

Generic Constructions This specification defines two generic cryptographic constructions:

1. 128-bit Block Cipher Construction:
   • Used in deterministic encryption (see )
   • Operates on a single 16-byte block
   • Example: AES-128 treated as a permutation
2. 128-bit Tweakable Block Cipher (TBC) Construction:
   • Used in non-deterministic encryption (see )
   • Accepts a key, a tweak, and a message
   • The tweak must be uniformly random when generated
   • Reuse of the same tweak on different inputs does not compromise confidentiality

Valid options for implementing a tweakable block cipher include, but are not limited to:

• SKINNY (see )
• DEOXYS-BC (see )
• KIASU-BC (see for implementation details)
• AES-XTS (see for usage)

Implementers MUST choose a cipher that provides robust resistance against related-tweak and other cryptographic attacks.

Deterministic Encryption Deterministic encryption applies a 128-bit block cipher directly to the 16-byte representation of an IP address, producing the same ciphertext for the same input and key. Deterministic encryption is appropriate when:

• Duplicate IP addresses need to be detected in encrypted form (e.g., for rate limiting)
• Storage space is critical (produces only 16 bytes output)
• Format preservation is required (output remains a valid IP address)
• Correlation of the same address across records is acceptable

All instantiations (ipcrypt-deterministic, ipcrypt-pfx, ipcrypt-nd, and ipcrypt-ndx) are invertible. For non-deterministic modes, the tweak must be preserved along with the ciphertext to enable decryption. Implementation details are provided in .

ipcrypt-deterministic The ipcrypt-deterministic instantiation employs AES-128 in a single-block operation. The key MUST be 16 bytes (128 bits). As AES-128 is a permutation, each distinct input maps to a unique ciphertext, preserving the IP address format. Test vectors are provided in .

Format Preservation and Limitations

Network Hierarchy Preservation Most encryption methods in this specification scramble network hierarchy, with the notable exception of ipcrypt-pfx:

• ipcrypt-deterministic, ipcrypt-nd, and ipcrypt-ndx: These methods completely scramble IPv4 and IPv6 prefixes in the encrypted output. Addresses from the same subnet appear unrelated after encryption, and geographic or topological proximity cannot be inferred.
• ipcrypt-pfx: This method preserves network prefix relationships in the encrypted output. Addresses from the same subnet share a common encrypted prefix, enabling network-level analytics while protecting the actual network identity. The encrypted prefixes themselves are cryptographically transformed and unrecognizable without the key.

Format Preservation Without Prefix Preservation For methods other than ipcrypt-pfx, IPv4 addresses are typically encrypted as IPv6 addresses. IPv4 format preservation without prefix preservation (maintaining IPv4 addresses as IPv4 in deterministic or non-deterministic modes) is not specified in this document and is generally discouraged due to the limited 32-bit address space, which significantly reduces encryption security. If IPv4 format preservation is absolutely required despite the security limitations, implementers SHOULD implement a Format-Preserving Encryption (FPE) mode such as the FF1 algorithm specified in or FAST .

Preserving Metadata for Analytics Organizations requiring network metadata for analytics have two options:

1. Use ipcrypt-pfx to preserve network structure within the encrypted addresses, enabling network-level analysis while keeping actual network identities encrypted.
2. For non-prefix-preserving modes (ipcrypt-deterministic, ipcrypt-nd, ipcrypt-ndx), extract and store metadata (geographic location, ASN, network classification) as separate fields before encryption.

Both approaches provide advantages over IP address truncation, which provides inconsistent protection and irreversibly destroys data. Recommended approach: 1. Extract metadata (geographic location, ASN, network type) from the original IP address 2. Store this information as separate fields alongside the encrypted IP address 3. Apply appropriate privacy-preserving aggregation to the metadata itself Example storage schema: ~~~ { “encrypted_ip”: “bde9:6789:d353:824c:d7c6:f58a:6bd2:26eb”, “country”: “US”, “asn”: 15169, “network_type”: “cloud_provider” } ~~~

Prefix-Preserving Encryption Prefix-preserving encryption maintains network structure in encrypted IP addresses. Addresses from the same network produce encrypted addresses that share a common prefix, enabling privacy-preserving network analytics while preventing identification of specific networks or users. Unlike standard encryption that completely scrambles addresses, prefix-preserving encryption enables network operators to:

• Detect traffic patterns from common networks without knowing which specific networks
• Perform network-level rate limiting on encrypted addresses
• Implement DDoS mitigation while preserving user privacy
• Analyze network topology without accessing raw IP addresses

This mode balances privacy with analytical capability: individual addresses remain encrypted and network identities are cryptographically transformed, but network relationships remain visible through shared encrypted prefixes.

Prefix-Preserving Construction The encryption process achieves prefix preservation through a bit-by-bit transformation that maintains consistency across addresses with shared prefixes. For any two IP addresses sharing the first N bits, their encrypted forms also share the first N bits. This property holds recursively for all prefix lengths. The algorithm operates as follows:

1. Process each bit position sequentially from most significant to least significant
2. For each bit position, extract the prefix (all bits processed so far) from the original IP address
3. Apply a pseudorandom function (PRF) that takes the padded prefix as input to generate a cipher bit
4. XOR the cipher bit with the original bit at the current position to produce the encrypted bit
5. The encrypted bit depends deterministically on the prefix from the original IP, ensuring identical prefixes always produce identical encrypted prefixes

This construction ensures:

• Identical prefixes always produce identical transformations for subsequent bits
• Different prefixes produce cryptographically distinct transformations
• The transformation is deterministic yet cryptographically secure
• Network relationships are preserved while actual network identities remain encrypted

The algorithm maintains native address sizes: IPv4 addresses remain 4 bytes (32 bits) and IPv6 addresses remain 16 bytes (128 bits).

Concrete Instantiation: ipcrypt-pfx The ipcrypt-pfx instantiation implements prefix-preserving encryption using a pseudorandom function based on the XOR of two independently keyed AES-128 encryptions.

Pseudorandom Function Construction The pseudorandom function requires a 32-byte key split into two independent 16-byte AES-128 keys (K1 and K2). For each bit position, the algorithm performs:

1. Padding: The prefix (all bits processed so far from the original IP address) is padded to 128 bits using the format zeros || 1 || prefix_bits, where:
   • The prefix bits are extracted from the most significant bits of the original IP address
   • A single 1 bit serves as a delimiter at position prefix_len_bits
   • The prefix bits are placed immediately after the delimiter, from high to low positions
   • For an empty prefix (processing the first bit), this produces a block with only a single 1 bit at position 0
2. Dual Encryption: The padded prefix is encrypted independently with both K1 and K2, producing two 128-bit outputs (e1 and e2).
3. XOR Combination: The final PRF output is computed as e = e1 ⊕ e2.

Bit Encryption Process For each bit position (processing from MSB to LSB):

1. Pad the prefix (bits processed so far from the original IP) to 128 bits
2. Compute the PRF output using the padded prefix: e = AES(K1, padded_prefix) ⊕ AES(K2, padded_prefix)
3. Extract the least significant bit from the PRF output as the cipher bit
4. XOR the cipher bit with the original bit at the current position to produce the encrypted bit

Complete pseudocode implementation is provided in .

Key Requirements The two 16-byte halves of the 32-byte key (K1 and K2) MUST NOT be identical. Using identical values for K1 and K2 (e.g., repeating the same 16 bytes twice) causes the XOR operation to cancel out, returning the original IP address unchanged. When the 32-byte key is randomly sampled from a uniform distribution, the probability that K1 = K2 is statistically negligible.

Security Properties The ipcrypt-pfx construction improves upon earlier designs such as CRYPTO-Pan through enhanced cryptographic security:

• Sum-of-Permutations: The XOR of two independently keyed AES-128 permutations provides security beyond the birthday bound , supporting more than 2⁷⁸ distinct IP addresses per key . This construction ensures that even with billions of encrypted addresses, security remains robust.
• Prefix-Based Context Isolation: Each bit depends on the entire prefix history.

Note: Prefix-preserving encryption intentionally reveals network structure to enable analytics. Organizations requiring complete address obfuscation should use non-prefix-preserving modes.

Implementation Considerations Key implementation characteristics:

• Computational Requirements:
  • IPv4: 64 AES-128 operations per address (2 encryptions × 32 bits)
  • IPv6: 256 AES-128 operations per address (2 encryptions × 128 bits)
• Performance Optimizations:
  • Caching encrypted prefix values (e1 and e2) significantly improves performance for addresses sharing common prefixes
  • The encryption algorithm is inherently parallelizable since AES computations for different bit positions are independent
  • The padded prefix computation can be optimized by maintaining state across iterations: instead of recomputing the padded prefix from scratch for each bit position, implementations can shift the previous padded prefix left by one bit and insert the next input bit.

Non-Deterministic Encryption Non-deterministic encryption enhances privacy by ensuring that the same IP address produces different ciphertexts each time it is encrypted, preventing correlation attacks that plague deterministic schemes. This is achieved through tweakable block ciphers that incorporate random values called tweaks. Non-deterministic encryption is appropriate when:

• Preventing correlation of the same IP address across records is critical
• Storage can accommodate the additional tweak data (8-16 bytes)
• Stronger privacy guarantees than deterministic encryption provides are required
• Processing the same address multiple times without revealing repetition patterns

Implementation details are provided in .

Encryption Process Encryption process for non-deterministic modes:

1. Generate a random tweak using a cryptographically secure random number generator
2. Convert the IP address to its 16-byte representation
3. Encrypt the 16-byte representation using the key and the tweak
4. Concatenate the tweak with the encrypted output to form the final ciphertext

The tweak is not considered secret and is included in the ciphertext, enabling its use for decryption.

Decryption Process Decryption process:

1. Split the ciphertext into the tweak and the encrypted IP
2. Decrypt the encrypted IP using the key and the tweak
3. Convert the resulting 16-byte representation back to an IP address

Although the tweak is generated uniformly at random, occasional collisions may occur according to birthday bounds. An (input, tweak) collision reveals that the same input was encrypted with the same tweak but does not disclose the input’s value. The usage limits apply per cryptographic key; rotating keys extends secure usage beyond these bounds.

Output Format and Encoding The output of non-deterministic encryption is binary data. For text representation, the binary output MUST be encoded (e.g., hexadecimal or Base64). Implementations SHOULD document their chosen encoding method.

Concrete Instantiations This document defines two concrete instantiations:

• ipcrypt-nd: Uses the KIASU-BC tweakable block cipher with an 8-byte (64-bit) tweak. See for details.
• ipcrypt-ndx: Uses the AES-XTS tweakable block cipher with a 16-byte (128-bit) tweak. See for background.

In both cases, if a tweak is generated randomly, it MUST be uniformly random. Reusing the same randomly generated tweak on different inputs is acceptable from a confidentiality standpoint. Test vectors are provided in and .

ipcrypt-nd (KIASU-BC) The ipcrypt-nd instantiation uses the KIASU-BC tweakable block cipher with an 8-byte (64-bit) tweak. Implementation details are provided in . The output is 24 bytes total, consisting of an 8-byte tweak concatenated with a 16-byte ciphertext. Random sampling of an 8-byte tweak yields an expected collision after about 2³² operations (approximately 4 billion). An (input, tweak) collision indicates repetition without revealing the input’s value. These collision bounds apply per cryptographic key. Regular key rotation can extend secure usage beyond these bounds. The effective security is determined by the underlying block cipher’s strength. Test vectors are provided in .

ipcrypt-ndx (AES-XTS) The ipcrypt-ndx instantiation uses the AES-XTS tweakable block cipher with a 16-byte (128-bit) tweak. The output is 32 bytes total, consisting of a 16-byte tweak concatenated with a 16-byte ciphertext. For single-block AES-XTS, independent sampling of a 16-byte tweak results in an expected collision after about 2⁶⁴ operations (approximately 18 quintillion). Similar to ipcrypt-nd, collisions reveal repetition without compromising the input value. These limits are per key, and regular key rotation extends secure usage. The effective security is governed by AES-128 strength (approximately 2¹²⁸ operations).

Comparison of Modes Mode selection depends on specific privacy requirements and operational constraints:

• Deterministic (ipcrypt-deterministic):
  • Output size: 16 bytes (most compact)
  • Privacy: Same IP always produces same ciphertext (allows correlation)
  • Use case: When duplicate identification is needed or when format preservation is critical
  • Performance: Fastest (single AES operation)
• Prefix-Preserving (ipcrypt-pfx):
  • Output size: 4 bytes for IPv4, 16 bytes for IPv6 (maintains native sizes)
  • Privacy: Preserves network prefix relationships while encrypting actual network identities
  • Use case: Network analytics, traffic pattern analysis, subnet monitoring, DDoS mitigation
  • Performance: Bit-by-bit processing (64 AES operations for IPv4, 256 for IPv6)
• Non-Deterministic ipcrypt-nd (KIASU-BC):
  • Output size: 24 bytes (16-byte ciphertext + 8-byte tweak)
  • Privacy: Same IP produces different ciphertexts (prevents most correlation)
  • Use case: General privacy protection with reasonable storage overhead
  • Collision resistance: Approximately 4 billion operations per key
• Non-Deterministic ipcrypt-ndx (AES-XTS):
  • Output size: 32 bytes (16-byte ciphertext + 16-byte tweak)
  • Privacy: Same IP produces different ciphertexts (prevents correlation)
  • Use case: Maximum privacy protection when storage permits
  • Collision resistance: Approximately 18 quintillion operations per key

Alternatives to Random Tweaks While this specification recommends uniformly random tweaks for non-deterministic encryption, alternative approaches may be considered:

• Monotonic Counter: A counter could be used as a tweak, but this is difficult to maintain in distributed systems. If the counter is not encrypted and the tweakable block cipher is not secure against related-tweak attacks, this could enable correlation attacks.
• UUIDs: UUIDs (such as UUIDv6 or UUIDv7) could be used as tweaks; however, these would reveal the original timestamp of the logged IP addresses, which may not be desirable from a privacy perspective.

Although the birthday bound presents considerations with random tweaks, random tweaks remain the recommended approach for practical deployments.

Security Considerations The methods specified in this document provide strong confidentiality guarantees but explicitly do not provide integrity protection: These methods provide protection against:

• Unauthorized parties learning the original IP addresses (without the key)
• Statistical analysis revealing patterns in network traffic (non-deterministic modes)
• Brute-force attacks on the address space (128-bit security level)

These methods do not provide protection against:

• Active attackers modifying, reordering, or removing encrypted addresses
• Authorized key holders decrypting addresses (by design)
• Traffic analysis based on volume and timing (metadata)

Applications requiring integrity protection must additionally employ authentication mechanisms such as HMAC, authenticated encryption modes, or digital signatures over the encrypted data.

Deterministic Mode Security A permutation ensures distinct inputs yield distinct outputs. Repeated inputs result in identical ciphertexts, revealing repetition. This makes deterministic encryption suitable for applications where format preservation is required and linkability is acceptable.

Non-Deterministic Mode Security The inclusion of a random tweak ensures that encrypting the same input generally produces different outputs. An (input, tweak) collision reveals only that the same input was processed with that tweak, not the input’s value. Security is determined by the underlying block cipher (≈2¹²⁸ for AES-128) on a per-key basis. Key rotation is recommended to extend secure usage beyond the per-key collision bounds.

Implementation Security Implementations MUST ensure that:

1. Keys are generated using a cryptographically secure random number generator
2. Tweak values are uniformly random for non-deterministic modes
3. Side-channel attacks are mitigated through constant-time operations
4. Error handling does not leak sensitive information

Key Management Considerations Implementers MUST ensure:

1. Keys are generated using cryptographically secure random number generators (see )
2. Keys are stored securely and access-controlled appropriately for the deployment environment
3. Key rotation policies are established based on usage volume and security requirements
4. Key compromise procedures are defined and tested

For high-volume deployments processing billions of IP addresses, regular key rotation (e.g., monthly or quarterly) is RECOMMENDED to stay well within the security bounds discussed in this document.

Implementation Details This section provides pseudocode and implementation guidance for the operations described in this document. In the pseudocode throughout this document, the notation “for i from x to y” indicates iteration starting at x (inclusive) and ending before y (exclusive). For example, “for i from 0 to 4” processes values 0, 1, 2, and 3, but not 4.

Visual Diagrams The following diagrams illustrate the processes described in this specification.

IPv4 Address Conversion Diagram

Deterministic Encryption Flow

Prefix-Preserving Encryption Flow (ipcrypt-pfx)

Non-Deterministic Encryption Flow (ipcrypt-nd)

Non-Deterministic Encryption Flow (ipcrypt-ndx)

IPv4 Address Conversion See for a diagram of this process. Example: For "192.0.2.1", the function returns

IPv6 Address Conversion > 8) & 0xFF low_byte = word & 0xFF bytes16.append(high_byte) bytes16.append(low_byte) return bytes16 ]]> Example: For "2001:0db8:85a3:0000:0000:8a2e:0370:7334", the output is the corresponding 16-byte sequence {0x20, 0x01, 0x0d, 0xb8, ..., 0x34}.

Conversion from a 16-Byte Array to an IP Address String This function converts a 16-byte array back to an IP address string. For IPv6 addresses, the output conforms to . Implementers SHOULD use existing IP address formatting functions from standard libraries. best_run_length: best_run_start = run_start best_run_length = run_length run_start = -1 // Check final run if run_start != -1: run_length = 8 - run_start if run_length > best_run_length: best_run_start = run_start best_run_length = run_length // Build IPv6 string with zero compression parts = [] i = 0 while i < 8: if best_run_length > 1 and i == best_run_start: // Insert :: for compressed zeros parts.append("" if i == 0 else ":") parts.append("") i += best_run_length else: parts.append(format_hex(words[i])) i += 1 return join(parts, ":") ]]>

Deterministic Encryption (ipcrypt-deterministic)

Encryption

Decryption

Prefix-Preserving Encryption (ipcrypt-pfx)

Encryption

Decryption

Helper Functions The following helper functions are used in the ipcrypt-pfx implementation: > bit_index) & 1 function set_bit(data, position, value): // Set bit at position in 16-byte array representing an IPv6 address in network byte order // position: 0 = LSB of byte 15, 127 = MSB of byte 0 byte_index = 15 - (position / 8) bit_index = position % 8 data[byte_index] |= ((value & 1) << bit_index) function pad_prefix(data, prefix_len_bits): // Specialized for the only two cases used: 0 and 96 // For prefix_len_bits=0: Returns a block with only bit 0 set (position 0 = LSB of byte 15) // For prefix_len_bits=96: Returns the IPv4-mapped prefix with separator at position 96 if prefix_len_bits == 0: // For IPv6 addresses starting from bit 0 padded_prefix = [0] * 16 padded_prefix[15] = 0x01 // Set bit at position 0 (LSB of byte 15) return padded_prefix else if prefix_len_bits == 96: // For IPv4 addresses, always returns the same value since all IPv4 addresses // share the same IPv4-mapped prefix (00...00 ffff) padded_prefix = [0] * 16 padded_prefix[3] = 0x01 // Set separator bit at position 96 (bit 0 of byte 3) padded_prefix[14] = 0xFF // IPv4-mapped prefix padded_prefix[15] = 0xFF // IPv4-mapped prefix return padded_prefix else: raise Error("pad_prefix only supports prefix_len_bits of 0 or 96") function shift_left_one_bit(data): // Shift a 16-byte array one bit to the left // The most significant bit is lost, and a zero bit is shifted in from the right result = [0] * 16 carry = 0 // Process from least significant byte (byte 15) to most significant byte (byte 0) for i from 15 down to 0: // Current byte shifted left by 1, with carry from previous byte result[i] = ((data[i] << 1) | carry) & 0xFF // Extract the bit that will be carried to the next byte carry = (data[i] >> 7) & 1 return result ]]>

Non-Deterministic Encryption using KIASU-BC (ipcrypt-nd)

Encryption

Decryption

Non-Deterministic Encryption using AES-XTS (ipcrypt-ndx)

Encryption

Decryption

Helper Functions for AES-XTS

KIASU-BC Implementation Guide This section provides a guide for implementing the KIASU-BC tweakable block cipher used in ipcrypt-nd.

Overview KIASU-BC extends AES-128 by incorporating an 8-byte tweak into each round. The tweak is padded to 16 bytes and XORed with the round key at each round.

Tweak Padding The 8-byte tweak is padded to 16 bytes using the following method:

1. Split the 8-byte tweak into four 2-byte pairs
2. Place each 2-byte pair at the start of each 4-byte group
3. Fill the remaining 2 bytes of each group with zeros

Example:

Round Structure Each round of KIASU-BC consists of the following standard AES operations:

1. SubBytes: Apply the AES S-box to each byte of the state
2. ShiftRows: Rotate each row of the state matrix
3. MixColumns: Mix the columns of the state matrix (except in the final round)
4. AddRoundKey: XOR the state with the round key and padded tweak

Details about these operations are provided in .

Key Schedule The key schedule follows the standard AES-128 key expansion:

1. The initial key is expanded into 11 round keys
2. Each round key is XORed with the padded tweak before use
3. The first round key is used in the initial AddRoundKey operation

Implementation Steps

1. Key Expansion:
   • Expand the 16-byte key into 11 round keys using the standard AES key schedule
   • Each round key is 16 bytes
2. Tweak Processing:
   • Pad the 8-byte tweak to 16 bytes as described above
   • XOR the padded tweak with each round key before use
3. Encryption Process:
   • Perform initial AddRoundKey with the first tweaked round key
   • For rounds 1-9:
     • SubBytes
     • ShiftRows
     • MixColumns
     • AddRoundKey (with tweaked round key)
   • For round 10 (final round):
     • SubBytes
     • ShiftRows
     • AddRoundKey (with tweaked round key)

Example Implementation The following pseudocode illustrates the core operations of KIASU-BC: Key and tweak sizes for each variant:

• ipcrypt-deterministic: Key: 16 bytes (128 bits), no tweak, Output: 16 bytes
• ipcrypt-pfx: Key: 32 bytes (256 bits, split into two independent AES-128 keys), no external tweak (uses prefix as cryptographic context), Output: 4 bytes for IPv4, 16 bytes for IPv6
• ipcrypt-nd: Key: 16 bytes (128 bits), Tweak: 8 bytes (64 bits), Output: 24 bytes
• ipcrypt-ndx: Key: 32 bytes (256 bits, split into two AES-128 keys), Tweak: 16 bytes (128 bits), Output: 32 bytes

Implementation Status This section is to be removed before publishing as an RFC. This section records the status of known implementations of the protocol defined by this specification at the time of posting of this Internet-Draft, and is based on a proposal described in . Multiple independent, interoperable implementations have been developed and include Awk, C, D, Dart, Elixir, Go, Java, JavaScript, Kotlin, PHP, Python, Ruby, Rust, Swift, and Zig. A comprehensive list of implementations and their test results is available at: https://ipcrypt-std.github.io/implementations/ All implementations pass the common test vectors specified in this document, demonstrating interoperability across programming languages.

Licensing This section is to be removed before publishing as an RFC. Implementations of the ipcrypt methods are freely available under permissive open source licenses (MIT, BSD, or Apache 2.0) at the repository listed in the Implementation Status section. There are no known patent claims on these methods.

References Normative References National Institute of Standards and Technology National Institute of Standards and Technology This document offers guidance for developing privacy considerations for inclusion in protocol specifications. It aims to make designers, implementers, and users of Internet protocols aware of privacy-related design choices. It suggests that whether any individual RFC warrants a specific privacy considerations section will depend on the document's content. Since the initial revelations of pervasive surveillance in 2013, several classes of attacks on Internet communications have been discovered. In this document, we develop a threat model that describes these attacks on Internet confidentiality. We assume an attacker that is interested in undetected, indiscriminate eavesdropping. The threat model is based on published, verified attacks. Pervasive monitoring is a technical attack that should be mitigated in the design of IETF protocols, where possible. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This specification defines the addressing architecture of the IP Version 6 (IPv6) protocol. The document includes the IPv6 addressing model, text representations of IPv6 addresses, definition of IPv6 unicast addresses, anycast addresses, and multicast addresses, and an IPv6 node's required addresses. This document obsoletes RFC 3513, "IP Version 6 Addressing Architecture". [STANDARDS-TRACK] Security systems are built on strong cryptographic algorithms that foil pattern analysis attempts. However, the security of these systems is dependent on generating secret quantities for passwords, cryptographic keys, and similar quantities. The use of pseudo-random processes to generate secret quantities can result in pseudo-security. A sophisticated attacker may find it easier to reproduce the environment that produced the secret quantities and to search the resulting small set of possibilities than to locate the quantities in the whole of the potential number space. Choosing random quantities to foil a resourceful and motivated adversary is surprisingly difficult. This document points out many pitfalls in using poor entropy sources or traditional pseudo-random number generation techniques for generating such quantities. It recommends the use of truly random hardware techniques and shows that the existing hardware on many systems can be used for this purpose. It provides suggestions to ameliorate the problem when a hardware solution is not available, and it gives examples of how large such quantities need to be for some applications. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. As IPv6 deployment increases, there will be a dramatic increase in the need to use IPv6 addresses in text. While the IPv6 address architecture in Section 2.2 of RFC 4291 describes a flexible model for text representation of an IPv6 address, this flexibility has been causing problems for operators, system engineers, and users. This document defines a canonical textual representation format. It does not define a format for internal storage, such as within an application or database. It is expected that the canonical format will be followed by humans and systems when representing IPv6 addresses as text, but all implementations must accept and be able to handle any legitimate RFC 4291 format. [STANDARDS-TRACK] This document describes a simple process that allows authors of Internet-Drafts to record the status of known implementations by including an Implementation Status section. This will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. This process is not mandatory. Authors of Internet-Drafts are encouraged to consider using the process for their documents, and working groups are invited to think about applying the process to all of their protocol specifications. This document obsoletes RFC 6982, advancing it to a Best Current Practice. Informative References

Test Vectors This appendix provides test vectors for the ipcrypt variants. Each test vector includes the key, input IP address, and encrypted output. Non-deterministic variants include the tweak value. Implementations MUST verify their correctness against these test vectors before deployment.

ipcrypt-deterministic Test Vectors

ipcrypt-pfx Test Vectors The following test vectors demonstrate the prefix-preserving property of ipcrypt-pfx. Addresses from the same network produce encrypted addresses that share a common encrypted prefix.

Basic Test Vectors

Prefix-Preserving Test Vectors These test vectors demonstrate the prefix-preserving property. Addresses from the same network share common encrypted prefixes at the corresponding prefix length.

ipcrypt-nd Test Vectors

ipcrypt-ndx Test Vectors For non-deterministic variants, the tweak values shown are examples. Tweaks MUST be uniformly random for each encryption operation.

IANA Considerations This document does not require any IANA actions.

Acknowledgments We would like to thank the members of the IETF and the cryptographic community for their helpful comments on this work. Tobias Fiebig conducted a detailed review of this draft. Additional valuable feedback was provided by Eliot Lear. Assistance with implementation aspects was kindly provided by Wu Tingfeng.