IPv6 networking support

mikedzikowski commented 2 years ago

Benefit/Result/Outcome

A customer has a request for IPv6 Support with MLZ deployments at each tier

Description

Update bicep templates for networking deployment to support, configure and deploy IPv6 for vNets/Subnets/Networking

Acceptance Criteria

IPv6 is supported in MLZ deployments using dual-stacked networks
Azure Bicep is updated so that it is flexible to deploy IPv4 or IPv6 or IPv6 dual-stacked or IPv6 only networks (https://docs.microsoft.com/en-us/azure/virtual-network/ip-services/ipv6-overview)
Update documentation on how to add IPv6 support to existing IPv4 only deployments (https://docs.microsoft.com/en-us/azure/load-balancer/ipv6-add-to-existing-vnet-powershell)
Array types are added for address prefixes (instead of current string types)
Array types are added for subnets

DPirnia commented 2 years ago

Additional information from the customers who are using MLZ for their program: At a high level, I think we need to be able to include IPv6 networking info in the deployment scripts (especially for Tier-3), but ultimately we want to be able to include IPv6 info any time we are specifying IPv4 info. Our engineer identified where it might be best to make changes (see below), but there were additional considerations he wanted to explore (especially re: firewalls and ExpressRoute). I asked him to provide as much detail as possible.

From the vNet / vNet peering component it looks very easy.

Updating the virtualNetwork module to support multiple address prefixes should allow IPv6 ranges to be set for the vNet and subnets.

Azure calls them dual stack vNets. Same thing should apply for subnets as well. Standard caveat that I haven’t tested these changes, but this is what I’d look at first.

Azure Firewall doesn’t support IPv6 rules yet. I’m not sure the roadmap / timeline on that. I’m not sure exactly how we’ll be routing our traffic, but this could be a blocker.

ExpressRoute does support IPv6. If we route traffic down the ExpressRoute to the NIH Firewall then out to the internet IPv6 would work fine. We’d just need to update the MLZ to configure the route tables to do this.

DPirnia commented 2 years ago

accidentally clicked close sorry!

lisamurphy-msft commented 2 years ago

I think this can be potentially implemented if we "add" ipv6 to the subnets or create new. According to this article We can potentially add an ipv6 subnet to the peered vnet to accomplish this: https://docs.microsoft.com/en-us/azure/virtual-network/ip-services/ipv6-overview This is not a desired configuration for many customers; would it be possible to create an example or add-on utility to alter the existing peered vnets? There appears to be CLI guidance at least on how to add ipv6 address prefixes to existing ipv4 assets in Azure: https://docs.microsoft.com/en-us/azure/load-balancer/ipv6-add-to-existing-vnet-cli

Please correct me if I am making incorrect assumptions

DPirnia commented 2 years ago

Lisa, thanks for adding the comments. Please make sure you sync with Mike D. He is adding the "acceptance criteria" to the issue to ensure that the production dependency our customer has on IPV6 will be satisfied with the planned work in our backlog.

Regards, Denise Pirnia, PMP(r), PMI-ACP(r), CSM Program Manager, Mission Solutions and Customer Expansion Microsoft Corporation, Mission Engineering 301-771-8375 | @.**@.>

[Microsoft Logo]

@. [CHANGE PRACTITIONER Prosci] @. http://aka.ms/CFSI @. @.

Confidentiality statement This E-mail and any of its attachments may contain Microsoft proprietary information, which is privileged, confidential, or subject to copyright belonging to Microsoft Corporation. This E-mail is intended solely for the internal use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

lisamurphy-msft commented 2 years ago

New acceptance criteria added, thank you @mikedzikowski ! This configurable pattern of offering three different "flavors" of networking configuration is worth considering. Will need to consider the possibility of incorporating this with Azure Firewall, as previously stated by @DPirnia Another thought on this might be Azure Front Door as a CDN, but I'm not certain on the availability of this option in disparate clouds: https://docs.microsoft.com/en-us/azure/frontdoor/front-door-overview

The first thing we can do is change the type of the addressPrefix into an array datatype instead of a string, that allows for multiple prefixes to be added to the vnet.

brooke-hamilton commented 2 years ago

Maybe consider array type to allow multiple subnets.

lisamurphy-msft commented 2 years ago

Created a backlog item to start this work that involves changing the data type to an array for subnets and address prefixes. This is only a pre-cursor to this ask though but I will link it here: #710

jamasten commented 2 weeks ago

Not supported for AVD

Azure / missionlz