Repository: envoyproxy/gateway

Issue:
Highlight release wait
```
Do not proceed until your PR has merged into the release branch and the [Build and Test](https://github.com/envoyproxy/gateway/blob/main/.github/workflows/build_and_test.yaml) has completed for your PR.
```

Hints from issue comments:

Solution patch:
diff --git a/api/v1alpha1/shared_types.go b/api/v1alpha1/shared_types.go
index 08ca30976..c9872b993 100644
--- a/api/v1alpha1/shared_types.go
+++ b/api/v1alpha1/shared_types.go
@@ -239,7 +239,7 @@ type KubernetesContainerSpec struct {
 	// The default tag will be used.
 	// This field is mutually exclusive with Image.
 	//
-	// +kubebuilder:validation:XValidation:rule="self.matches('^[a-zA-Z0-9._/-]+$')",message="ImageRepository must contain only allowed characters and must not include a tag or any colons."
+	// +kubebuilder:validation:XValidation:rule="self.matches('^[a-zA-Z0-9._-]+(:[0-9]+)?[a-zA-Z0-9._/-]+$')",message="ImageRepository must contain only allowed characters and must not include a tag."
 	// +optional
 	ImageRepository *string `json:"imageRepository,omitempty"`
 
diff --git a/charts/gateway-crds-helm/templates/generated/gateway.envoyproxy.io_envoyproxies.yaml b/charts/gateway-crds-helm/templates/generated/gateway.envoyproxy.io_envoyproxies.yaml
index 5cb364725..bca62d14d 100644
--- a/charts/gateway-crds-helm/templates/generated/gateway.envoyproxy.io_envoyproxies.yaml
+++ b/charts/gateway-crds-helm/templates/generated/gateway.envoyproxy.io_envoyproxies.yaml
@@ -623,8 +623,8 @@ spec:
                                 type: string
                                 x-kubernetes-validations:
                                 - message: ImageRepository must contain only allowed
-                                    characters and must not include a tag or any colons.
-                                  rule: self.matches('^[a-zA-Z0-9._/-]+$')
+                                    characters and must not include a tag.
+                                  rule: self.matches('^[a-zA-Z0-9._-]+(:[0-9]+)?[a-zA-Z0-9._/-]+$')
                               resources:
                                 description: |-
                                   Resources required by this container.
@@ -4468,8 +4468,8 @@ spec:
                                 type: string
                                 x-kubernetes-validations:
                                 - message: ImageRepository must contain only allowed
-                                    characters and must not include a tag or any colons.
-                                  rule: self.matches('^[a-zA-Z0-9._/-]+$')
+                                    characters and must not include a tag.
+                                  rule: self.matches('^[a-zA-Z0-9._-]+(:[0-9]+)?[a-zA-Z0-9._/-]+$')
                               resources:
                                 description: |-
                                   Resources required by this container.
diff --git a/charts/gateway-helm/crds/generated/gateway.envoyproxy.io_envoyproxies.yaml b/charts/gateway-helm/crds/generated/gateway.envoyproxy.io_envoyproxies.yaml
index 6302ee471..fe454279c 100644
--- a/charts/gateway-helm/crds/generated/gateway.envoyproxy.io_envoyproxies.yaml
+++ b/charts/gateway-helm/crds/generated/gateway.envoyproxy.io_envoyproxies.yaml
@@ -622,8 +622,8 @@ spec:
                                 type: string
                                 x-kubernetes-validations:
                                 - message: ImageRepository must contain only allowed
-                                    characters and must not include a tag or any colons.
-                                  rule: self.matches('^[a-zA-Z0-9._/-]+$')
+                                    characters and must not include a tag.
+                                  rule: self.matches('^[a-zA-Z0-9._-]+(:[0-9]+)?[a-zA-Z0-9._/-]+$')
                               resources:
                                 description: |-
                                   Resources required by this container.
@@ -4467,8 +4467,8 @@ spec:
                                 type: string
                                 x-kubernetes-validations:
                                 - message: ImageRepository must contain only allowed
-                                    characters and must not include a tag or any colons.
-                                  rule: self.matches('^[a-zA-Z0-9._/-]+$')
+                                    characters and must not include a tag.
+                                  rule: self.matches('^[a-zA-Z0-9._-]+(:[0-9]+)?[a-zA-Z0-9._/-]+$')
                               resources:
                                 description: |-
                                   Resources required by this container.
diff --git a/site/content/en/contributions/RELEASING.md b/site/content/en/contributions/RELEASING.md
index 5d27ed1b0..809e2af59 100644
--- a/site/content/en/contributions/RELEASING.md
+++ b/site/content/en/contributions/RELEASING.md
@@ -40,48 +40,48 @@ export GITHUB_REMOTE=origin
 
    __Note:__ The release candidate version should be in the format `${MAJOR_VERSION}.${MINOR_VERSION}.0-rc.${RELEASE_CANDIDATE_NUMBER}`.
 3. Sign, commit, and push your changes to your fork.
-4. Submit a [Pull Request][] to merge the changes into the `main` branch. Do not proceed until your PR has merged and
-   the [Build and Test][] has successfully completed.
-5. Create a new release branch from `main`. The release branch should be named
+4. Submit a [Pull Request][] to merge the changes into the `main` branch. 
+5. Do not proceed until your PR has merged and the [Build and Test][] has successfully completed.
+6. Create a new release branch from `main`. The release branch should be named
    `release/v${MAJOR_VERSION}.${MINOR_VERSION}`, e.g. `release/v0.3`.
 
    ```shell
    git checkout -b release/v${MAJOR_VERSION}.${MINOR_VERSION}
    ```
 
-6. Push the branch to the Envoy Gateway repo.
+7. Push the branch to the Envoy Gateway repo.
 
     ```shell
     git push ${GITHUB_REMOTE} release/v${MAJOR_VERSION}.${MINOR_VERSION}
     ```
 
-7. Create a topic branch for updating the Envoy proxy image and Envoy Ratelimit image to the tag supported by the release.
+8. Create a topic branch for updating the Envoy proxy image and Envoy Ratelimit image to the tag supported by the release.
  Please note that the tags should be updated in both the source code and the Helm chart. Reference [PR #2098][]
    for additional details on updating the image tag.
-8. Sign, commit, and push your changes to your fork.
-9. Submit a [Pull Request][] to merge the changes into the `release/v${MAJOR_VERSION}.${MINOR_VERSION}` branch. Do not
-   proceed until your PR has merged into the release branch and the [Build and Test][] has completed for your PR.
-10. Ensure your release branch is up-to-date and tag the head of your release branch with the release candidate number.
+9. Sign, commit, and push your changes to your fork.
+10. Submit a [Pull Request][] to merge the changes into the `release/v${MAJOR_VERSION}.${MINOR_VERSION}` branch. 
+11. Do not proceed until your PR has merged into the release branch and the [Build and Test][] has completed for your PR.
+12. Ensure your release branch is up-to-date and tag the head of your release branch with the release candidate number.
 
     ```shell
     git tag -a v${MAJOR_VERSION}.${MINOR_VERSION}.0-rc.${RELEASE_CANDIDATE_NUMBER} -m 'Envoy Gateway v${MAJOR_VERSION}.${MINOR_VERSION}.0-rc.${RELEASE_CANDIDATE_NUMBER} Release Candidate'
     ```
 
-11. Push the tag to the Envoy Gateway repository.
+13. Push the tag to the Envoy Gateway repository.
 
     ```shell
     git push ${GITHUB_REMOTE} v${MAJOR_VERSION}.${MINOR_VERSION}.0-rc.${RELEASE_CANDIDATE_NUMBER}
     ```
 
-12. This will trigger the [release GitHub action][] that generates the release, release artifacts, etc.
-13. Confirm that the [release workflow][] completed successfully.
-14. Confirm that the Envoy Gateway [image][] with the correct release tag was published to Docker Hub.
-15. Confirm that the [release][] was created.
-16. Note that the [Quickstart][] references are __not__ updated for release candidates. However, test
+14. This will trigger the [release GitHub action][] that generates the release, release artifacts, etc.
+15. Confirm that the [release workflow][] completed successfully.
+16. Confirm that the Envoy Gateway [image][] with the correct release tag was published to Docker Hub.
+17. Confirm that the [release][] was created.
+18. Note that the [Quickstart][] references are __not__ updated for release candidates. However, test
     the quickstart steps using the release candidate by manually updating the links.
-17. [Generate][] the GitHub changelog.
-18. Ensure you check the "This is a pre-release" checkbox when editing the GitHub release.
-19. If you find any bugs in this process, please create an issue.
+19. [Generate][] the GitHub changelog.
+20. Ensure you check the "This is a pre-release" checkbox when editing the GitHub release.
+21. If you find any bugs in this process, please create an issue.
 
 ## Minor Release
 
@@ -170,16 +170,17 @@ export GITHUB_REMOTE=origin
       ```
 
 3. Sign, commit, and push your changes to your fork.
-4. Submit a [Pull Request][] to merge the changes into the `main` branch. Do not proceed until all your PRs have merged
-   and the [Build and Test][] has completed for your final PR.
+4. Submit a [Pull Request][] to merge the changes into the `main` branch.
 
-5. Checkout the release branch.
+5. Do not proceed until all your PRs have merged and the [Build and Test][] has completed for your final PR.
+
+6. Checkout the release branch.
 
    ```shell
    git checkout release/v${MAJOR_VERSION}.${MINOR_VERSION} $GITHUB_REMOTE/release/v${MAJOR_VERSION}.${MINOR_VERSION}
    ```
 
-6. If the tip of the release branch does not match the tip of `main`, perform the following:
+7. If the tip of the release branch does not match the tip of `main`, perform the following:
 
    1. Create a topic branch from the release branch.
    2. Cherry-pick the commits from `main` that differ from the release branch, e.g. `git cherry-pick <present commit in rc>..<latest commit on main> -s`
@@ -199,7 +200,7 @@ export GITHUB_REMOTE=origin
       git pull $GITHUB_REMOTE release/v${MAJOR_VERSION}.${MINOR_VERSION}
       ```
 
-7. Tag the head of your release branch with the release tag. For example:
+8. Tag the head of your release branch with the release tag. For example:
 
     ```shell
     git tag -a v${MAJOR_VERSION}.${MINOR_VERSION}.0 -m 'Envoy Gateway v${MAJOR_VERSION}.${MINOR_VERSION}.0 Release'
@@ -207,18 +208,18 @@ export GITHUB_REMOTE=origin
 
     __Note:__ The tag version differs from the release branch by including the `.0` patch version.
 
-8. Push the tag to the Envoy Gateway repository.
+9. Push the tag to the Envoy Gateway repository.
 
      ```shell
      git push origin v${MAJOR_VERSION}.${MINOR_VERSION}.0
      ```
 
-9.  This will trigger the [release GitHub action][] that generates the release, release artifacts, etc.
-10. Confirm that the [release workflow][] completed successfully.
-11. Confirm that the Envoy Gateway [image][] with the correct release tag was published to Docker Hub.
-12. Confirm that the [release][] was created.
-13. Confirm that the steps in the [Quickstart][] work as expected.
-14. [Generate][] the GitHub changelog and include the following text at the beginning of the release page:
+10. This will trigger the [release GitHub action][] that generates the release, release artifacts, etc.
+11. Confirm that the [release workflow][] completed successfully.
+12. Confirm that the Envoy Gateway [image][] with the correct release tag was published to Docker Hub.
+13. Confirm that the [release][] was created.
+14. Confirm that the steps in the [Quickstart][] work as expected.
+15. [Generate][] the GitHub changelog and include the following text at the beginning of the release page:
 
    ```console
    # Release Announcement
@@ -227,7 +228,7 @@ export GITHUB_REMOTE=origin
    (https://gateway.envoyproxy.io/news/releases/notes/v${MAJOR_VERSION}.${MINOR_VERSION}.html) to learn more about the release.
    ```
 
-15. Update the `lastVersionTag` in `test/e2e/tests/eg_upgrade.go` to reflect the latest prior release. Refer to [PR #4666] as an example.
+16. Update the `lastVersionTag` in `test/e2e/tests/eg_upgrade.go` to reflect the latest prior release. Refer to [PR #4666] as an example.
 
 If you find any bugs in this process, please create an issue.
 
@@ -313,21 +314,20 @@ export GITHUB_REMOTE=origin
       ```
 
 3. Sign, commit, and push your changes to your fork.
-4. Submit a [Pull Request][] to merge the changes into the `main` branch. Do not proceed until all your PRs have merged
-   and the [Build and Test][] has completed for your final PR.
-
-5. Checkout the release branch.
+4. Submit a [Pull Request][] to merge the changes into the `main` branch. 
+5. Do not proceed until all your PRs have merged and the [Build and Test][] has completed for your final PR.
+6. Checkout the release branch.
 
    ```shell
    git checkout release/v${MAJOR_VERSION}.${MINOR_VERSION} $GITHUB_REMOTE/release/v${MAJOR_VERSION}.${MINOR_VERSION}
    ```
 
-6. Cherry-pick the release note and release announcement that you created in the previous step to the release branch. The release note will be included in the release artifacts.
+7. Cherry-pick the release note and release announcement that you created in the previous step to the release branch. The release note will be included in the release artifacts.
    1. Create a topic branch from the release branch.
    2. Cherry-pick the release note and release announcement commit from `main` to the topic branch.
    3. Submit a PR to merge the topic from of your fork into the release branch.
 
-7. Cherry-pick the commits that you want to include in the patch release.
+8. Cherry-pick the commits that you want to include in the patch release.
    1. Create a topic branch from the release branch.
    2. Cherry-pick the commits from `main` that you want to include in the patch release.
    3. Run tests locally, e.g. `make lint`.
@@ -346,24 +346,24 @@ export GITHUB_REMOTE=origin
       git pull $GITHUB_REMOTE release/v${MAJOR_VERSION}.${MINOR_VERSION}
       ```
 
-7. Tag the head of your release branch with the release tag. For example:
+9. Tag the head of your release branch with the release tag. For example:
 
     ```shell
     git tag -a v${MAJOR_VERSION}.${MINOR_VERSION}.${PATCH_VERSION} -m 'Envoy Gateway v${MAJOR_VERSION}.${MINOR_VERSION}.${PATCH_VERSION} Release'
     ```
 
-8. Push the tag to the Envoy Gateway repository.
+10. Push the tag to the Envoy Gateway repository.
 
-     ```shell
-     git push origin v${MAJOR_VERSION}.${MINOR_VERSION}.${PATCH_VERSION
-     ```
+      ```shell
+      git push origin v${MAJOR_VERSION}.${MINOR_VERSION}.${PATCH_VERSION
+      ```
 
-9.  This will trigger the [release GitHub action][] that generates the release, release artifacts, etc.
-10. Confirm that the [release workflow][] completed successfully.
-11. Confirm that the Envoy Gateway [image][] with the correct release tag was published to Docker Hub.
-12. Confirm that the [release][] was created.
-13. Confirm that the steps in the [Quickstart][] work as expected.
-14. [Generate][] the GitHub changelog and include the following text at the beginning of the release page:
+11. This will trigger the [release GitHub action][] that generates the release, release artifacts, etc.
+12. Confirm that the [release workflow][] completed successfully.
+13. Confirm that the Envoy Gateway [image][] with the correct release tag was published to Docker Hub.
+14. Confirm that the [release][] was created.
+15. Confirm that the steps in the [Quickstart][] work as expected.
+16. [Generate][] the GitHub changelog and include the following text at the beginning of the release page:
 
    ```console
    # Release Announcement
@@ -372,7 +372,7 @@ export GITHUB_REMOTE=origin
    (https://gateway.envoyproxy.io/news/releases/notes/v${MAJOR_VERSION}.${MINOR_VERSION}.${MINOR_VERSION}.html) to learn more about the release.
    ```
 
-15. If this patch release is the latest release, update the `lastVersionTag` in `test/e2e/tests/eg_upgrade.go` to reflect the latest prior release. Refer to [PR #4666] as an example.
+17. If this patch release is the latest release, update the `lastVersionTag` in `test/e2e/tests/eg_upgrade.go` to reflect the latest prior release. Refer to [PR #4666] as an example.
 
 ### Announce the Release
 



Test patch:
diff --git a/internal/infrastructure/kubernetes/proxy/resource_test.go b/internal/infrastructure/kubernetes/proxy/resource_test.go
index d295944fa..6f8511d60 100644
--- a/internal/infrastructure/kubernetes/proxy/resource_test.go
+++ b/internal/infrastructure/kubernetes/proxy/resource_test.go
@@ -105,6 +105,13 @@ func TestResolveProxyImage(t *testing.T) {
 			},
 			expected: fmt.Sprintf("envoyproxy/envoy:%s", defaultTag),
 		},
+		{
+			name: "imageRepository with port",
+			container: &egv1a1.KubernetesContainerSpec{
+				ImageRepository: ptr.To("docker.io:443/envoyproxy/envoy"),
+			},
+			expected: fmt.Sprintf("docker.io:443/envoyproxy/envoy:%s", defaultTag),
+		},
 	}
 
 	for _, tc := range tests {
diff --git a/site/content/en/latest/concepts/gateway_api_extensions/backend-traffic-policy.md b/site/content/en/latest/concepts/gateway_api_extensions/backend-traffic-policy.md
index 1cc981a1b..06c99d39e 100644
--- a/site/content/en/latest/concepts/gateway_api_extensions/backend-traffic-policy.md
+++ b/site/content/en/latest/concepts/gateway_api_extensions/backend-traffic-policy.md
@@ -29,17 +29,58 @@ Think of it as a traffic controller between your gateway and backend services. I
 
 `BackendTrafficPolicy` is part of the Envoy Gateway API suite, which extends the Kubernetes Gateway API with additional capabilities. It's implemented as a Custom Resource Definition (CRD) that you can use to configure how Envoy Gateway manages traffic to your backend services.
 
-You can attach it to Gateway API resources in two ways:
+### Targets
 
-1. Using `targetRefs` to directly reference specific Gateway resources
-2. Using `targetSelectors` to match Gateway resources based on labels
+BackendTrafficPolicy can be attached to Gateway API resources using two targeting mechanisms:
 
-The policy applies to all resources that match either targeting method. When multiple policies target the same resource, the most specific configuration wins.
+1. **Direct Reference (`targetRefs`)**: Explicitly reference specific resources by name and kind.
+2. **Label Selection (`targetSelectors`)**: Match resources based on their labels (see [targetSelectors API reference](../../api/extension_types#targetselectors))
 
-For example, consider these two policies:
+```yaml
+# Direct reference targeting
+apiVersion: gateway.envoyproxy.io/v1alpha1
+kind: BackendTrafficPolicy
+metadata:
+  name: direct-policy
+spec:
+  targetRefs:
+    - kind: HTTPRoute
+      name: my-route
+  circuitBreaker:
+    maxConnections: 50
+
+---
+# Label-based targeting
+apiVersion: gateway.envoyproxy.io/v1alpha1
+kind: BackendTrafficPolicy
+metadata:
+  name: selector-policy
+spec:
+  targetSelectors:
+    - kind: HTTPRoute
+      matchLabels:
+        app: payment-service
+  rateLimit:
+    type: Local
+    local:
+      requests: 10
+      unit: Second
+```
+
+The policy applies to all resources that match either targeting method. You can target various Gateway API resource types including
+`Gateway`, `HTTPRoute`, `GRPCRoute`, `TCPRoute`, `UDPRoute`, `TLSRoute`.
+
+**Important**: A BackendTrafficPolicy can only target resources in the same namespace as the policy itself.
+
+### Precedence
+
+When multiple BackendTrafficPolicies apply to the same resource, Envoy Gateway resolves conflicts using a precedence hierarchy based on the target resource type, regardless of how the policy was attached:
+
+1. **Route-level policies** (HTTPRoute, GRPCRoute, etc.) - Highest precedence
+2. **Gateway-level policies** - Lower precedence
 
 ```yaml
-# Policy 1: Applies to all routes in the gateway
+# Gateway-level policy (lower precedence) - Applies to all routes in the gateway
 apiVersion: gateway.envoyproxy.io/v1alpha1
 kind: BackendTrafficPolicy
 metadata:
@@ -52,7 +93,7 @@ spec:
     maxConnections: 100
 
 ---
-# Policy 2: Applies to a specific route
+# Route-level policy (higher precedence)
 apiVersion: gateway.envoyproxy.io/v1alpha1
 kind: BackendTrafficPolicy
 metadata:
@@ -65,9 +106,47 @@ spec:
     maxConnections: 50
 ```
 
-In this example `my-route` and `my-gateway` would both affect the route. However, since Policy 2 targets the route directly while Policy 1 targets the gateway, Policy 2's configuration (`maxConnections: 50`) will take precedence for that specific route.
+In this example, the HTTPRoute `my-route` would use `maxConnections: 50` from the route-level policy, overriding the gateway-level setting of 100.
+
+#### Multiple Policies at the Same Level
+
+When multiple BackendTrafficPolicies target the same resource at the same hierarchy level (e.g., multiple policies targeting the same HTTPRoute), Envoy Gateway uses the following tie-breaking rules:
+
+1. **Creation Time Priority**: The oldest policy (earliest `creationTimestamp`) takes precedence
+2. **Name-based Sorting**: If policies have identical creation timestamps, they are sorted alphabetically by namespaced name, with the first policy taking precedence
+
+```yaml
+# Policy created first - takes precedence
+apiVersion: gateway.envoyproxy.io/v1alpha1
+kind: BackendTrafficPolicy
+metadata:
+  name: alpha-policy
+  creationTimestamp: "2023-01-01T10:00:00Z"
+spec:
+  targetRefs:
+    - kind: HTTPRoute
+      name: my-route
+  circuitBreaker:
+    maxConnections: 30
+
+---
+# Policy created later - lower precedence
+apiVersion: gateway.envoyproxy.io/v1alpha1
+kind: BackendTrafficPolicy
+metadata:
+  name: beta-policy
+  creationTimestamp: "2023-01-01T11:00:00Z"
+spec:
+  targetRefs:
+    - kind: HTTPRoute
+      name: my-route
+  circuitBreaker:
+    maxConnections: 40
+```
+
+In this example, `alpha-policy` would take precedence due to its earlier creation time, so the HTTPRoute would use `maxConnections: 30`.
 
-Lastly, it's important to note that even when you apply a policy to a Gateway, the policy's effects are tracked separately for each backend service referenced in your routes. For example, if you set up circuit breaking on a Gateway with multiple backend services, each backend service will have its own independent circuit breaker counter. This ensures that issues with one backend service don't affect the others.
+When the `mergeType` field is unset, no merging occurs and only the most specific configuration takes effect. However, policies can be configured to merge with parent policies using the `mergeType` field (see [Policy Merging](#policy-merging) section below).
 
 ## Policy Merging
 
diff --git a/site/content/en/latest/concepts/gateway_api_extensions/client-traffic-policy.md b/site/content/en/latest/concepts/gateway_api_extensions/client-traffic-policy.md
index 8dc47a306..b5afbfb06 100644
--- a/site/content/en/latest/concepts/gateway_api_extensions/client-traffic-policy.md
+++ b/site/content/en/latest/concepts/gateway_api_extensions/client-traffic-policy.md
@@ -36,14 +36,67 @@ Think of `ClientTrafficPolicy` as a set of rules for your Gateway's entry points
 
 `ClientTrafficPolicy` is part of the Envoy Gateway API suite, which extends the Kubernetes Gateway API with additional capabilities. It's implemented as a Custom Resource Definition (CRD) that you can use to configure how Envoy Gateway manages incoming client traffic.
 
-You can attach it to Gateway API resources in two ways:
+### Targets
 
-1. Using `targetRefs` to directly reference specific Gateway resources
-2. Using `targetSelectors` to match Gateway resources based on labels
+ClientTrafficPolicy can be attached to Gateway API resources using two targeting mechanisms:
 
-The policy applies to all Gateway resources that match either targeting method. When multiple policies target the same resource, the most specific configuration wins.
+1. **Direct Reference (`targetRefs`)**: Explicitly reference specific Gateway resources by name and kind.
+2. **Label Selection (`targetSelectors`)**: Match Gateway resources based on their labels (see [targetSelectors API reference](../../api/extension_types#targetselectors))
 
-For example, consider these policies targeting the same Gateway Listener:
+The policy applies to all Gateway resources that match either targeting method.
+
+**Important**: A ClientTrafficPolicy can only target Gateway resources in the same namespace as the policy itself.
+
+### Precedence
+
+When multiple ClientTrafficPolicies apply to the same resource, Envoy Gateway resolves conflicts using section-level specificity and creation-time priority:
+
+1. **Section-specific policies** (targeting specific listeners via `sectionName`) - Highest precedence
+2. **Gateway-wide policies** (targeting entire Gateway) - Lower precedence
+
+#### Multiple Policies at the Same Level
+
+When multiple ClientTrafficPolicies target the same resource at the same specificity level (e.g., multiple policies targeting the same Gateway listener section), Envoy Gateway uses the following tie-breaking rules:
+
+1. **Creation Time Priority**: The oldest policy (earliest `creationTimestamp`) takes precedence
+2. **Name-based Sorting**: If policies have identical creation timestamps, they are sorted alphabetically by namespaced name, with the first policy taking precedence
+
+```yaml
+# Policy created first - takes precedence
+apiVersion: gateway.envoyproxy.io/v1alpha1
+kind: ClientTrafficPolicy
+metadata:
+  name: alpha-policy
+  creationTimestamp: "2023-01-01T10:00:00Z"
+spec:
+  targetRefs:
+    - kind: Gateway
+      name: my-gateway
+      sectionName: https-listener
+  timeout:
+    http:
+      idleTimeout: 30s
+
+---
+# Policy created later - lower precedence
+apiVersion: gateway.envoyproxy.io/v1alpha1
+kind: ClientTrafficPolicy
+metadata:
+  name: beta-policy
+  creationTimestamp: "2023-01-01T11:00:00Z"
+spec:
+  targetRefs:
+    - kind: Gateway
+      name: my-gateway
+      sectionName: https-listener
+  timeout:
+    http:
+      idleTimeout: 40s
+```
+
+In this example, `alpha-policy` would take precedence due to its earlier creation time, so the listener would use `idleTimeout: 30s`.
+
+For example, consider these policies with different specificity levels targeting the same Gateway:
 
 ```yaml
 # Policy A: Targets a specific listener in the gateway
diff --git a/site/content/en/latest/concepts/gateway_api_extensions/security-policy.md b/site/content/en/latest/concepts/gateway_api_extensions/security-policy.md
index 12f0eccfd..4eac2fb50 100644
--- a/site/content/en/latest/concepts/gateway_api_extensions/security-policy.md
+++ b/site/content/en/latest/concepts/gateway_api_extensions/security-policy.md
@@ -27,14 +27,146 @@ title: "SecurityPolicy"
 
 ## SecurityPolicy in Envoy Gateway
 
-`SecurityPolicy` is implemented as a Kubernetes Custom Resource Definition (CRD) and follows the policy attachment model. You can attach it to Gateway API resources in two ways:
+`SecurityPolicy` is implemented as a Kubernetes Custom Resource Definition (CRD) and follows the policy attachment model. 
 
-1. Using `targetRefs` to directly reference specific Gateway resources
-2. Using `targetSelectors` to match Gateway resources based on labels
+### Targets
 
-The policy applies to all resources that match either targeting method. When multiple policies target the same resource, the most specific configuration wins.
+SecurityPolicy can be attached to Gateway API resources using two targeting mechanisms:
 
-For example, consider these policies targeting the same Gateway Listener:
+1. **Direct Reference (`targetRefs`)**: Explicitly reference specific resources by name and kind.
+2. **Label Selection (`targetSelectors`)**: Match resources based on their labels (see [targetSelectors API reference](../../api/extension_types#targetselectors))
+
+The policy applies to all resources that match either targeting method. You can target various Gateway API resource types including `Gateway`, `HTTPRoute`, and `GRPCRoute`.
+
+**Important**: A SecurityPolicy can only target resources in the same namespace as the policy itself.
+
+### Precedence
+
+When multiple SecurityPolicies apply to the same resource, Envoy Gateway resolves conflicts using a precedence hierarchy based on the target resource type and section-level specificity:
+
+1. **Route rule-level policies** (HTTPRoute/GRPCRoute with `sectionName` targeting specific rules) - Highest precedence
+2. **Route-level policies** (HTTPRoute, GRPCRoute without `sectionName`) - High precedence  
+3. **Listener-level policies** (Gateway with `sectionName` targeting specific listeners) - Medium precedence
+4. **Gateway-level policies** (Gateway without `sectionName`) - Lowest precedence
+
+#### Multiple Policies at the Same Level
+
+When multiple SecurityPolicies target the same resource at the same hierarchy level (e.g., multiple policies targeting the same HTTPRoute), Envoy Gateway uses the following tie-breaking rules:
+
+1. **Creation Time Priority**: The oldest policy (earliest `creationTimestamp`) takes precedence
+2. **Name-based Sorting**: If policies have identical creation timestamps, they are sorted alphabetically by namespaced name, with the first policy taking precedence
+
+```yaml
+# Policy created first - takes precedence
+apiVersion: gateway.envoyproxy.io/v1alpha1
+kind: SecurityPolicy
+metadata:
+  name: alpha-policy
+  creationTimestamp: "2023-01-01T10:00:00Z"
+spec:
+  targetRefs:
+    - kind: HTTPRoute
+      name: my-route
+  cors:
+    allowOrigins:
+      - exact: https://example.com
+
+---
+# Policy created later - lower precedence
+apiVersion: gateway.envoyproxy.io/v1alpha1
+kind: SecurityPolicy
+metadata:
+  name: beta-policy
+  creationTimestamp: "2023-01-01T11:00:00Z"
+spec:
+  targetRefs:
+    - kind: HTTPRoute
+      name: my-route
+  cors:
+    allowOrigins:
+      - exact: https://different.com
+```
+
+In this example, `alpha-policy` would take precedence due to its earlier creation time, so the HTTPRoute would use the CORS setting from `alpha-policy`.
+
+```yaml
+# HTTPRoute with named rules
+apiVersion: gateway.networking.k8s.io/v1
+kind: HTTPRoute
+metadata:
+  name: my-route
+spec:
+  rules:
+  - name: rule-1  # Named rule for sectionName targeting
+    matches:
+    - path:
+        value: "/api"
+    backendRefs:
+    - name: api-service
+      port: 80
+
+---
+# Route rule-level policy (highest precedence)
+apiVersion: gateway.envoyproxy.io/v1alpha1
+kind: SecurityPolicy
+metadata:
+  name: rule-policy
+spec:
+  targetRef:
+    kind: HTTPRoute
+    name: my-route
+    sectionName: rule-1  # Targets specific named rule
+  cors:
+    allowOrigins:
+    - exact: https://rule.example.com
+
+---
+# Route-level policy (high precedence)
+apiVersion: gateway.envoyproxy.io/v1alpha1
+kind: SecurityPolicy
+metadata:
+  name: route-policy
+spec:
+  targetRef:
+    kind: HTTPRoute
+    name: my-route  # No sectionName = entire route
+  cors:
+    allowOrigins:
+    - exact: https://route.example.com
+
+---
+# Listener-level policy (medium precedence)
+apiVersion: gateway.envoyproxy.io/v1alpha1
+kind: SecurityPolicy
+metadata:
+  name: listener-policy
+spec:
+  targetRef:
+    kind: Gateway
+    name: my-gateway
+    sectionName: https-listener  # Targets specific listener
+  cors:
+    allowOrigins:
+    - exact: https://listener.example.com
+
+---
+# Gateway-level policy (lowest precedence)
+apiVersion: gateway.envoyproxy.io/v1alpha1
+kind: SecurityPolicy
+metadata:
+  name: gateway-policy
+spec:
+  targetRef:
+    kind: Gateway
+    name: my-gateway  # No sectionName = entire gateway
+  cors:
+    allowOrigins:
+    - exact: https://gateway.example.com
+```
+
+In this example, the specific rule `rule-1` within HTTPRoute `my-route` would use the CORS settings from the route rule-level policy (`https://rule.example.com`), overriding the route-level, listener-level, and gateway-level settings.
+
+For section-specific targeting, consider these policies with different hierarchy levels targeting the same Gateway:
 
 ```yaml
 # Policy A: Applies to a specific listener
diff --git a/site/content/en/latest/tasks/extensibility/envoy-patch-policy.md b/site/content/en/latest/tasks/extensibility/envoy-patch-policy.md
index 9fddf7dc5..72b047e3b 100644
--- a/site/content/en/latest/tasks/extensibility/envoy-patch-policy.md
+++ b/site/content/en/latest/tasks/extensibility/envoy-patch-policy.md
@@ -82,6 +82,89 @@ data:
 
 {{< boilerplate rollout-envoy-gateway >}}
 
+## XDS Name Scheme V2
+
+Starting from v1.5, Envoy Gateway uses version 2 of the xDS name scheme when generating xDS resources.
+Because [EnvoyPatchPolicy][] relies on specific xDS resource names, it’s important to use the correct naming format when authoring a patch policy.
+
+| Component            | Scheme Version | Format Description                                                          | Example                          |
+|----------------------|----------------|------------------------------------------------------------------------------|----------------------------------|
+| **Listener name**    | Old            | `<GatewayNamespace>/<GatewayName>/<GatewayListenerName>`                    | `default/eg/http`               |
+|                      | V2             | `<Protocol>-<Port>`                                                         | `tcp-80`                         |
+| **RouteConfig name** | Old            | `<GatewayNamespace>/<GatewayName>/<GatewayListenerName>`                    | `default/eg/http`               |
+|                      | V2 (HTTP)      | `http-<Port>`                                                               | `http-80`                       |
+|                      | V2 (HTTPS)     | `<GatewayNamespace>/<GatewayName>/<GatewayListenerName>`                    | `default/eg/https`               |
+| **FilterChain name** | Old            | `<GatewayNamespace>/<GatewayName>/<GatewayListenerName>`                    | `default/eg/http`               |
+|                      | V2 (HTTP)      | `http-<Port>`                                                               | `http-80`                        |
+|                      | V2 (HTTPS)     | `<GatewayNamespace>/<GatewayName>/<GatewayListenerName>`                    | `default/eg/https`               |
+| **VirtualHost name** | Old            | `<GatewayNamespace>/<GatewayName>/<GatewayListenerName>/<VirtualHost>`      | `default/eg/http/www_example_com` |
+|                      | V2             | `<VirtualHost>`                                                             | `www_example_com`               |
+| **HCM StatPrefix**   | Old            | `<ApplicationProtocol>/<ContainerPort>`                                     | `http-10080`, `https-10443`     |
+|                      | V2 (HTTP)      | `http-<Port>`                                                               | `http-80`                        |
+|                      | V2 (HTTPS)     | `https-<Port>`                                                              | `https-443`                      |
+
+
+This change is gated by the XDSNameSchemeV2 runtime flag. The flag is disabled by default in v1.5 and will be enabled by default starting in v1.6.
+
+We recommend users begin migrating their [EnvoyPatchPolicy][] resources to use the version 2 naming scheme before upgrading to v1.6.
+
+To opt in to the new naming scheme early, add the`XDSNameSchemeV2` runtime flag to the `runtimeFlags.enabled` field in your [EnvoyGateway][] configuration.
+
+{{< tabpane text=true >}}
+{{% tab header="Apply from stdin" %}}
+
+```shell
+cat <<EOF | kubectl apply -f -
+apiVersion: v1
+kind: ConfigMap
+metadata:
+  name: envoy-gateway-config
+  namespace: envoy-gateway-system
+data:
+  envoy-gateway.yaml: |
+    apiVersion: gateway.envoyproxy.io/v1alpha1
+    kind: EnvoyGateway
+    provider:
+      type: Kubernetes
+    gateway:
+      controllerName: gateway.envoyproxy.io/gatewayclass-controller
+    extensionApis:
+      enableEnvoyPatchPolicy: true
+    runtimeFlags:
+      enabled:
+      - XDSNameSchemeV2
+EOF
+```
+
+{{% /tab %}}
+{{% tab header="Apply from file" %}}
+Save and apply the following resource to your cluster:
+
+```yaml
+---
+apiVersion: v1
+kind: ConfigMap
+metadata:
+  name: envoy-gateway-config
+  namespace: envoy-gateway-system
+data:
+  envoy-gateway.yaml: |
+    apiVersion: gateway.envoyproxy.io/v1alpha1
+    kind: EnvoyGateway
+    provider:
+      type: Kubernetes
+    gateway:
+      controllerName: gateway.envoyproxy.io/gatewayclass-controller
+    extensionApis:
+      enableEnvoyPatchPolicy: true
+    runtimeFlags:
+      enabled:
+      - XDSNameSchemeV2
+```
+
+{{% /tab %}}
+{{< /tabpane >}}
+
 ## Testing
 
 ### Customize Response
diff --git a/site/content/en/latest/troubleshooting/admin-console.md b/site/content/en/latest/troubleshooting/admin-console.md
index b0aa56ce4..1289f7580 100644
--- a/site/content/en/latest/troubleshooting/admin-console.md
+++ b/site/content/en/latest/troubleshooting/admin-console.md
@@ -6,7 +6,7 @@ Envoy Gateway provides a built-in web-based admin console that offers a comprehe
 
 ## Prerequisites
 
-{{< boilerplate o11y_prerequisites >}}
+{{< boilerplate prerequisites >}}
 
 ## Overview
 
diff --git a/test/cel-validation/envoyproxy_test.go b/test/cel-validation/envoyproxy_test.go
index cd0e37995..0f7bf5d6b 100644
--- a/test/cel-validation/envoyproxy_test.go
+++ b/test/cel-validation/envoyproxy_test.go
@@ -1740,7 +1740,43 @@ func TestEnvoyProxyProvider(t *testing.T) {
 					},
 				}
 			},
-			wantErrors: []string{"ImageRepository must contain only allowed characters and must not include a tag or any colons."},
+			wantErrors: []string{"ImageRepository must contain only allowed characters and must not include a tag."},
+		},
+		{
+			desc: "valid: imageRepository set with port",
+			mutate: func(envoy *egv1a1.EnvoyProxy) {
+				envoy.Spec = egv1a1.EnvoyProxySpec{
+					Provider: &egv1a1.EnvoyProxyProvider{
+						Type: egv1a1.ProviderTypeKubernetes,
+						Kubernetes: &egv1a1.EnvoyProxyKubernetesProvider{
+							EnvoyDeployment: &egv1a1.KubernetesDeploymentSpec{
+								Container: &egv1a1.KubernetesContainerSpec{
+									ImageRepository: ptr.To("docker.io:443/envoyproxy/envoy"),
+								},
+							},
+						},
+					},
+				}
+			},
+			wantErrors: []string{},
+		},
+		{
+			desc: "invalid: imageRepository set with port and tag",
+			mutate: func(envoy *egv1a1.EnvoyProxy) {
+				envoy.Spec = egv1a1.EnvoyProxySpec{
+					Provider: &egv1a1.EnvoyProxyProvider{
+						Type: egv1a1.ProviderTypeKubernetes,
+						Kubernetes: &egv1a1.EnvoyProxyKubernetesProvider{
+							EnvoyDeployment: &egv1a1.KubernetesDeploymentSpec{
+								Container: &egv1a1.KubernetesContainerSpec{
+									ImageRepository: ptr.To("docker.io:443/envoyproxy/envoy:v1.2.3"),
+								},
+							},
+						},
+					},
+				}
+			},
+			wantErrors: []string{"ImageRepository must contain only allowed characters and must not include a tag."},
 		},
 	}
 
diff --git a/test/helm/gateway-crds-helm/all.out.yaml b/test/helm/gateway-crds-helm/all.out.yaml
index 3bc2a49e1..c32cc359f 100644
--- a/test/helm/gateway-crds-helm/all.out.yaml
+++ b/test/helm/gateway-crds-helm/all.out.yaml
@@ -24547,8 +24547,8 @@ spec:
                                 type: string
                                 x-kubernetes-validations:
                                 - message: ImageRepository must contain only allowed
-                                    characters and must not include a tag or any colons.
-                                  rule: self.matches('^[a-zA-Z0-9._/-]+$')
+                                    characters and must not include a tag.
+                                  rule: self.matches('^[a-zA-Z0-9._-]+(:[0-9]+)?[a-zA-Z0-9._/-]+$')
                               resources:
                                 description: |-
                                   Resources required by this container.
@@ -28392,8 +28392,8 @@ spec:
                                 type: string
                                 x-kubernetes-validations:
                                 - message: ImageRepository must contain only allowed
-                                    characters and must not include a tag or any colons.
-                                  rule: self.matches('^[a-zA-Z0-9._/-]+$')
+                                    characters and must not include a tag.
+                                  rule: self.matches('^[a-zA-Z0-9._-]+(:[0-9]+)?[a-zA-Z0-9._/-]+$')
                               resources:
                                 description: |-
                                   Resources required by this container.
diff --git a/test/helm/gateway-crds-helm/envoy-gateway-crds.out.yaml b/test/helm/gateway-crds-helm/envoy-gateway-crds.out.yaml
index 4ab5cb551..bf8389a94 100644
--- a/test/helm/gateway-crds-helm/envoy-gateway-crds.out.yaml
+++ b/test/helm/gateway-crds-helm/envoy-gateway-crds.out.yaml
@@ -7235,8 +7235,8 @@ spec:
                                 type: string
                                 x-kubernetes-validations:
                                 - message: ImageRepository must contain only allowed
-                                    characters and must not include a tag or any colons.
-                                  rule: self.matches('^[a-zA-Z0-9._/-]+$')
+                                    characters and must not include a tag.
+                                  rule: self.matches('^[a-zA-Z0-9._-]+(:[0-9]+)?[a-zA-Z0-9._/-]+$')
                               resources:
                                 description: |-
                                   Resources required by this container.
@@ -11080,8 +11080,8 @@ spec:
                                 type: string
                                 x-kubernetes-validations:
                                 - message: ImageRepository must contain only allowed
-                                    characters and must not include a tag or any colons.
-                                  rule: self.matches('^[a-zA-Z0-9._/-]+$')
+                                    characters and must not include a tag.
+                                  rule: self.matches('^[a-zA-Z0-9._-]+(:[0-9]+)?[a-zA-Z0-9._/-]+$')
                               resources:
                                 description: |-
                                   Resources required by this container.