(@aws-cdk/aws-ec2-alpha): secondaryAddressBlock IP validation disallows valid options

[domestic-fennec]

Describe the bug

The validateIpv4address function disallows VPCs with primaryAddressBlocks in 192.168.0.0/16 and 10.0.0.0/8 space to have secondaryAddressBlocks outside that space such as publicly routable IPv4 CIDR block which are valid as documented by aws: https://docs.aws.amazon.com/vpc/latest/userguide/vpc-cidr-blocks.html#add-cidr-block-restrictions

e.g primary 10.0.0.0/16 + 198.18.0.0/26

aws-cdk/packages/@aws-cdk/aws-ec2-alpha/lib/vpc-v2.ts

Lines 914 to 917 in 73b9f98

	return (ip1.octet1 === 10 && ip2.octet1 === 10) ||
	(ip1.octet1 === 192 && ip1.octet2 === 168 && ip2.octet1 === 192 && ip2.octet2 === 168) ||
	(ip1.octet1 === 172 && ip1.octet2 === 16 && ip2.octet1 === 172 && ip2.octet2 === 16); // CIDR ranges belong to same private IP address ranges
	}

Regression Issue

• Select this option if this issue appears to be a regression.

Last Known Working CDK Library Version

No response

Expected Behavior

It should be possible to add secondary address blocks from valid IP ranges other than the primary address block.

Current Behavior

Running npx cdk synth throws an error - "CIDR block should be in the same RFC 1918 range in the VPC"

/test/node_modules/@aws-cdk/aws-ec2-alpha/lib/vpc-v2.ts:556
            throw new Error('CIDR block should be in the same RFC 1918 range in the VPC');
                  ^
Error: CIDR block should be in the same RFC 1918 range in the VPC
    at new VpcV2 (/test/node_modules/@aws-cdk/aws-ec2-alpha/lib/vpc-v2.ts:556:19)
    at new VpcV2 (/test/node_modules/aws-cdk-lib/core/lib/prop-injectable.js:1:681)
    at Object.<anonymous> (/test/bin/vpc.ts:30:1)
    at Module._compile (node:internal/modules/cjs/loader:1734:14)
    at Module.m._compile (/test/node_modules/ts-node/src/index.ts:1618:23)
    at loadTS (node:internal/modules/cjs/loader:1826:10)
    at Object.require.extensions.<computed> [as .ts] (/test/node_modules/ts-node/src/index.ts:1621:12)
    at Module.load (node:internal/modules/cjs/loader:1469:32)
    at Module._load (node:internal/modules/cjs/loader:1286:12)
    at TracingChannel.traceSync (node:diagnostics_channel:322:14)
npx ts-node --prefer-ts-exts bin/vpc.ts: Subprocess exited with error 1

Reproduction Steps

import * as cdk from "aws-cdk-lib/core";
import * as ec2a from "@aws-cdk/aws-ec2-alpha";

const app = new cdk.App();
const stack = new cdk.Stack(app, "Stack");

new ec2a.VpcV2(stack, "Vpc", {
  primaryAddressBlock: ec2a.IpAddresses.ipv4("10.160.0.0/19"),
  secondaryAddressBlocks: [ec2a.IpAddresses.ipv4("198.18.0.0/26", { cidrBlockName: "tgw" })],
});

### Possible Solution

1. Write validation logic such that it allows all valid combinations.
2. Allow bypassing validation via an optional propertly.
3. Remove the validation altogether.

I appreciate the affordance offered by attempting to validate secondary ranges without needing to wait till deploying a cloudformation stack to find it won't work. Given that the current logic only tests a subset of possible combinations and writing exhaustive logic to validate all possible combinations might be a lot of work (and possibly require updates if cloudformation or ec2 modifies it's own rules in future), I can see the value in making it bypassable or simply removing it altogether.

### Additional Information/Context

There are various networking scenarios and AWS guidance that call for somewhat "unusual" seconday IP blocks on a VPC

https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/preserve-routable-ip-space-in-multi-account-vpc-designs-for-non-workload-subnets.html



### AWS CDK Library version (aws-cdk-lib)

2.225.0

### AWS CDK CLI version

2.1032.0

### Node.js Version

v24.1.0

### OS

OSX

### Language

TypeScript

### Language Version

5.9.3

### Other information

_No response_

[pahud]

The root cause seems to be validateIpv4address function that implements an overly restrictive
validation that contradicts AWS VPC's actual CIDR block requirements.

The validation logic incorrectly assumes:

• Secondary IPv4 CIDR blocks must be in the same RFC 1918 range as the primary block

AWS VPC actually allows:

• Mixing RFC 1918 private ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16)
• Adding publicly routable IPv4 CIDR blocks
• Using 100.64.0.0/10 (RFC 6598 shared address space)
• Various combinations as documented in AWS VPC CIDR block restrictions

For existing IPv4 address range 10.0.0.0/8:

Permitted associations:
- "Any publicly routable IPv4 CIDR block (non-RFC 1918) between a /16 netmask and /28 netmask or a CIDR block between a /16 netmask and /28 netmask from the 100.64.0.0/10 range."

For existing IPv4 address range 192.168.0.0/16:

Permitted associations:
- "Any publicly routable IPv4 CIDR block (non-RFC 1918) between a /16 netmask and /28 netmask or a CIDR block from the 100.64.0.0/10 range between a /16 netmask and /28 netmask."

For existing IPv4 address range 172.16.0.0/12:

Permitted associations:
- "Any publicly routable IPv4 CIDR block (non-RFC 1918) between a /16 netmask and /28 netmask or a CIDR block between a /16 netmask and /28 netmask from the 100.64.0.0/10 range."

So the AWS documentation explicitly allows:

1. RFC 1918 primary (10.0.0.0/8, 172.16.0.0/12, or 192.168.0.0/16) + publicly routable secondary (non-RFC 1918)
2. RFC 1918 primary + 100.64.0.0/10 secondary (shared address space)

But the CDK validation incorrectly rejects it.

Possible Fix

Replace the validateIpv4address function with proper AWS rules:

function validateIpv4address(cidr1?: string, cidr2?: string): boolean {
  if (!cidr1 || !cidr2) return false;

  const getRangeType = (cidr: string): string => {
    const octets = cidr.split('.').map(n => parseInt(n, 10));
    const first = octets[0];
    const second = octets[1];

    if (first === 10) return '10.0.0.0/8';
    if (first === 172 && second >= 16 && second <= 31) return '172.16.0.0/12';
    if (first === 192 && second === 168) return '192.168.0.0/16';
    if (first === 198 && second === 19) return '198.19.0.0/16';
    if (first === 100 && second >= 64 && second <= 127) return '100.64.0.0/10';
    return 'public';
  };

  const type1 = getRangeType(cidr1);
  const type2 = getRangeType(cidr2);

  // Restricted: RFC 1918 ranges cannot mix with each other
  const rfc1918 = ['10.0.0.0/8', '172.16.0.0/12', '192.168.0.0/16'];
  if (rfc1918.includes(type1) && rfc1918.includes(type2) && type1 !== type2) {
    return false;
  }

  // Restricted: 198.19.0.0/16 cannot mix with RFC 1918
  if ((type1 === '198.19.0.0/16' && rfc1918.includes(type2)) ||
      (type2 === '198.19.0.0/16' && rfc1918.includes(type1))) {
    return false;
  }

  // Restricted: public/100.64.0.0/10 cannot mix with RFC 1918 or 198.19.0.0/16
  // UNLESS the RFC 1918 is the primary (type2)
  if ((type1 === 'public' || type1 === '100.64.0.0/10') &&
      (rfc1918.includes(type2) || type2 === '198.19.0.0/16')) {
    return false;
  }

  return true;
}

(just a possible fix, might need further review)

We welcome PRs.