// If this field is present and contains at least one item, then this rule allows
  // traffic only if the traffic matches at least one port in the list.
  // +optional
  // +listType=atomic
  repeated NetworkPolicyPort ports = 1;

  // to is a list of destinations for outgoing traffic of pods selected for this rule.

apiVersion: release-notes/v2
kind: bug-fix
area: traffic-management
issue: 
  - 41271
releaseNotes:
  - |

apiVersion: release-notes/v2
kind: feature
area: traffic-management
issue:
- 48212
releaseNotes:
- |

	// ingress is a list of ingress rules to be applied to the selected pods.
	// Traffic is allowed to a pod if there are no NetworkPolicies selecting the pod
	// (and cluster policy otherwise allows the traffic), OR if the traffic source is
	// the pod's local node, OR if the traffic matches at least one ingress rule
	// across all of the NetworkPolicy objects whose podSelector matches the pod. If

    service IPs. (We *must* do this in `prerouting`, because the choice of endpoint IP may
    affect whether the packet then gets routed along the input path or the forward path.)

  - We do the DNAT for outbound traffic in `output`: this covers traffic coming from
    host-network processes to all types of service IPs. Regardless of the final
    destination, the traffic will take the "output path". (In the case where a

apiVersion: release-notes/v2
kind: feature
area: traffic-management
releaseNotes:
- |

understand. Under the old waypoint logic all types of traffic, both addressed to a service as well as addressed to a workload, were treated similarly because there wasn't a good way to properly associate a waypoint to a service. With the new attachment this limitation has been resolved. This includes adding a distinction between service addressed and workload addressed traffic. Annotating a service, or service-like kind, will redirect traffic which is service addressed to your waypoint. Likewise...

		return nil
	}
	return err
}

// configureIPv6Addresses sets up a new IP address on local interface. This is used as the source IP
// for inbound traffic to distinguish traffic we want to capture vs traffic we do not. This is needed
// for IPv6 but not IPv4, as IPv4 defaults to `netmask 255.0.0.0`, which allows binding to addresses

# Configure helloworld using the Kubernetes Gateway API

Istio intends to make the Kubernetes [Gateway API](https://gateway-api.sigs.k8s.io/) the default API for traffic management [in the future](https://istio.io/latest/blog/2022/gateway-api-beta/).
You can use the following instructions to configure the ingress gateway and routing for the helloworld sample.

## Before you begin

apiVersion: release-notes/v2
kind: feature
area: traffic-management
issue:
- 29359

releaseNotes:
- |
  **Added** support for hostname-based multi-network gateways for east-west traffic. The hostname will be resolved in
  the control plane and each of the IPs will be used as an endpoint. This behaviour can be disabled by setting