(ec2): Support for ipv6 in ec2.IVpc, ec2.ISubnet

[mrpackethead]

Describe the feature

It would be very helpful if ec2.IVpc and ec2.ISubnet could have additional properties added to them.

in ec2.IVpc, the addition of
vpcIPv6CidrBlock?: string

In ec2.ISubnet, the addition of
ipv6CidrBlock?: string

The creation of DualStack Vpcs and Subnets is a much bigger topic, and getting a replacement / upgrade to ec2.Vpc is a much bigger topic, that has been going on for a long time, and given the way that most folks want their own opinionated stacks, is unlikely to get resolved in the short term. However the underlying Interfaces which are relied on by many things, are a lot less contentious.

Use Case

Building Dual Stack VPC

Proposed Solution

No response

Other Information

No response

Acknowledgements

• I may be able to implement this feature request
• This feature might incur a breaking change

AWS CDK Library version (aws-cdk-lib)

any version

AWS CDK CLI version

any version

Environment details (OS name and version, etc.)

n/a

[pahud]

Hi @mrpackethead,

Thank you for this feature request! This is a valid and well-reasoned request that would improve the developer experience when working with dual-stack VPCs.

You're absolutely right that while full dual-stack VPC support is a complex topic, adding IPv6 CIDR properties to the IVpc and ISubnet interfaces would be a straightforward enhancement that provides immediate value.

Current Gap:
The concrete Vpc class already has IPv6 support with the vpcIpv6CidrBlocks property, but this isn't exposed through the IVpc interface. Similarly, subnet IPv6 information exists in the concrete implementations but isn't available through ISubnet.

Proposed Solution:

• Add readonly vpcIPv6CidrBlock?: string to IVpc interface
• Add readonly ipv6CidrBlock?: string to ISubnet interface
• Update concrete implementations to expose these properties
• Update import attributes for external VPCs/subnets

This would be a non-breaking change since the properties would be optional, and it would eliminate the need for users to cast to concrete types when working with IPv6 information.

This enhancement would complement the ongoing work in related issues like #33490 (Dual Stack VPC additions) and would be valuable for anyone building dual-stack infrastructure.

Would you be interested in contributing a PR for this enhancement? The implementation should be relatively straightforward and would be a great contribution to the CDK community.

Related issues: #33490, #31797, #29039

[related-issues-bot-for-aws]

Hi @mrpackethead,

Thanks for opening this issue! After reviewing the details, we found some other discussions that may be duplicates or closely related:

Potential Duplicate Issues

• (aws-ec2): vpcIpv6CidrBlocks missing from interface IVpc #19525: Both issues address the same technical gap - the lack of IPv6 CIDR block properties in the IVpc interface. Issue (aws-ec2): vpcIpv6CidrBlocks missing from interface IVpc #19525 specifically requests adding vpcIpv6CidrBlocks to the IVpc interface, while the current issue requests vpcIPv6CidrBlock (singular vs. plural naming). They target the same construct (ec2.IVpc), have the same goal of enabling better support for dual-stack VPCs, and would require the same implementation approach of exposing IPv6 CIDR information through the interface.

Related Issues

• Enabling IPv6 on Resources and VPCs #894: This issue relates to the broader topic of enabling IPv6 support across AWS CDK networking constructs. While the current issue focuses specifically on adding IPv6 CIDR properties to IVpc and ISubnet interfaces, issue Enabling IPv6 on Resources and VPCs #894 has a wider scope addressing IPv6 enablement across multiple resource types. Both share the common goal of improving dual-stack VPC capabilities but address different implementation aspects of the IPv6 support problem.

This message was generated automatically to help connect related conversations and improve discoverability.

If you feel this issue brings new or distinct information, feel free to add a comment to keep it open. Otherwise, we'll close this issue in 7 days if we don't recieve a response to help keep discussions consolidated.

Please react with 👍 or 👎 to let us know if this response was helpful!

Thank you for helping improve CDK! 🙌

[github-actions]

This issue has not received a response in a while. If you want to keep this issue open, please leave a comment below and auto-close will be canceled.