diff --git a/docs/proposals/00-template.md b/docs/proposals/00-template.md
index 2d7fed4e4..e458e472e 100644
--- a/docs/proposals/00-template.md
+++ b/docs/proposals/00-template.md
@@ -1,7 +1,7 @@
 ---
-title: OEP Title
+title: IEP Title
 
-oep-number: NNNN
+iep-number: NNNN
 
 creation-date: 20XX-XX-XX
 
@@ -19,16 +19,18 @@ reviewers:
 
 ---
 
-# OEP-NNNN: Your short, descriptive title
+# IEP-NNNN: Your short, descriptive title
 
 ## Table of Contents
 
-- [Summary](#summary)
-- [Motivation](#motivation)
+- [IEP-NNNN: Your short, descriptive title](#iep-nnnn-your-short-descriptive-title)
+  - [Table of Contents](#table-of-contents)
+  - [Summary](#summary)
+  - [Motivation](#motivation)
     - [Goals](#goals)
     - [Non-Goals](#non-goals)
-- [Proposal](#proposal)
-- [Alternatives](#alternatives)
+  - [Proposal](#proposal)
+  - [Alternatives](#alternatives)
 
 ## Summary
 
@@ -40,4 +42,4 @@ reviewers:
 
 ## Proposal
 
-## Alternatives
\ No newline at end of file
+## Alternatives
diff --git a/docs/proposals/01-networking-integration.md b/docs/proposals/01-networking-integration.md
index bdb14a87d..49cdc6b43 100644
--- a/docs/proposals/01-networking-integration.md
+++ b/docs/proposals/01-networking-integration.md
@@ -1,7 +1,7 @@
 ---
 title: Networking Integration
 
-oep-number: 1
+iep-number: 1
 
 creation-date: 2022-17-03
 
@@ -22,7 +22,7 @@ reviewers:
 
 ---
 
-# OEP-1: Networking Integration
+# IEP-1: Networking Integration
 
 ## Table of Contents
 
diff --git a/docs/proposals/02-machine-console-access.md b/docs/proposals/02-machine-console-access.md
index af5a0a863..c945dedb6 100644
--- a/docs/proposals/02-machine-console-access.md
+++ b/docs/proposals/02-machine-console-access.md
@@ -1,7 +1,7 @@
 ---
 title: Machine Console Access
 
-oep-number: 2
+iep-number: 2
 
 creation-date: 2022-12-05
 
@@ -19,16 +19,20 @@ reviewers:
 
 ---
 
-# OEP-02: Machine Console Access
+# IEP-02: Machine Console Access
 
 ## Table of Contents
 
-- [Summary](#summary)
-- [Motivation](#motivation)
+- [IEP-02: Machine Console Access](#IEP-02-machine-console-access)
+  - [Table of Contents](#table-of-contents)
+  - [Summary](#summary)
+  - [Motivation](#motivation)
     - [Goals](#goals)
     - [Non-Goals](#non-goals)
-- [Proposal](#proposal)
-- [Alternatives](#alternatives)
+  - [Proposal](#proposal)
+    - [User-facing API](#user-facing-api)
+    - [Server-Side API](#server-side-api)
+  - [Alternatives](#alternatives)
 
 ## Summary
 
diff --git a/docs/proposals/03-loadbalancer.md b/docs/proposals/03-loadbalancer.md
index d631793f6..a6b56c407 100644
--- a/docs/proposals/03-loadbalancer.md
+++ b/docs/proposals/03-loadbalancer.md
@@ -1,7 +1,7 @@
 ---
 title: Network Loadbalancer
 
-oep-number: 3
+iep-number: 3
 
 creation-date: 2022-10-18
 
@@ -21,16 +21,19 @@ reviewers:
 
 ---
 
-# OEP-3: Network Loadbalancer
+# IEP-3: Network Loadbalancer
 
 ## Table of Contents
 
-- [Summary](#summary)
-- [Motivation](#motivation)
+- [IEP-3: Network Loadbalancer](#IEP-3-network-loadbalancer)
+  - [Table of Contents](#table-of-contents)
+  - [Summary](#summary)
+  - [Motivation](#motivation)
     - [Goals](#goals)
     - [Non-Goals](#non-goals)
     - [Details](#details)
-- [Proposal](#proposal)
+  - [Proposal](#proposal)
+    - [Routing State Object](#routing-state-object)
 
 ## Summary
 
@@ -43,7 +46,7 @@ load balancers, since they can be used as a foundation for the higher level load
 
 ## Motivation
 
-A `VirtualIP` ([OEP-1](01-networking-integration.md#the-virtualip-type)) allows to expose a `NetworkInterface`
+A `VirtualIP` ([IEP-1](01-networking-integration.md#the-virtualip-type)) allows to expose a `NetworkInterface`
 with a stable public IP. Services running on a `Machine` using that `NetworkInterface` can be consumed this way.
 However, if the `Machine` or the service running on that `Machine` crashes, the service will have an outage.
 To be more resilient and to scale beyond single `NetworkInterface`s, a `LoadBalancer` allows targeting multiple
@@ -55,7 +58,7 @@ To be more resilient and to scale beyond single `NetworkInterface`s, a `LoadBala
 - Load balancers should allow specifying their IP stack (`IPv4` / `IPv6` / dual stack). Public IP addresses
   should be allocated according to the specified IP stack.
 - Load balancers should support multiple target `NetworkInterface`s (
-  see ([OEP-1](01-networking-integration.md#the-networkinterface-type))
+  see ([IEP-1](01-networking-integration.md#the-networkinterface-type))
 - The load balancer should dynamically watch for target `NetworkInterface`s.
 - All target `NetworkInterface`s must be in the same `Network`.
 - The load balancer should be able to filter unwanted traffic. The filtering must not alter the packages.
@@ -87,7 +90,7 @@ its `status.ips`.
 `ports` defines an allow list of which traffic should be handled by a `LoadBalancer`. A `port` consists of
 a `protocol`, `port` and an optional `portEnd` to support port range filtering.
 `networkRef` defines the target `Network` a `NetworkInterface` has to be in in order to be an eligible target
-for traffic forwarding (see [OEP-1](01-networking-integration.md#the-networkinterface-type)).
+for traffic forwarding (see [IEP-1](01-networking-integration.md#the-networkinterface-type)).
 
 [//]: # (@formatter:off)
 ```yaml
diff --git a/docs/proposals/04-nat-gateway.md b/docs/proposals/04-nat-gateway.md
index 8ccad8418..cdbf84c14 100644
--- a/docs/proposals/04-nat-gateway.md
+++ b/docs/proposals/04-nat-gateway.md
@@ -1,7 +1,7 @@
 ---
 title: NAT Gateway
 
-oep-number: 4
+iep-number: 4
 
 creation-date: 2022-18-10
 
@@ -21,15 +21,17 @@ reviewers:
 
 ---
 
-# OEP-4: Cloud Nate Gateway
+# IEP-4: Cloud Nate Gateway
 
 ## Table of Contents
 
-- [Summary](#summary)
-- [Motivation](#motivation)
+- [IEP-4: Cloud Nate Gateway](#IEP-4-cloud-nate-gateway)
+  - [Table of Contents](#table-of-contents)
+  - [Summary](#summary)
+  - [Motivation](#motivation)
     - [Goals](#goals)
     - [Non-Goals](#non-goals)
-- [Proposal](#proposal)
+  - [Proposal](#proposal)
 
 ## Summary
 
diff --git a/docs/proposals/05-object-storage.md b/docs/proposals/05-object-storage.md
index 5ff417808..b436e0cd3 100644
--- a/docs/proposals/05-object-storage.md
+++ b/docs/proposals/05-object-storage.md
@@ -1,7 +1,7 @@
 ---
 title: Object Storage
 
-oep-number: 5
+iep-number: 5
 
 creation-date: 2022-12-19
 
@@ -19,16 +19,21 @@ reviewers:
 
 ---
 
-# OEP-5: Object Storage
+# IEP-5: Object Storage
 
 ## Table of Contents
 
-- [Summary](#summary)
-- [Motivation](#motivation)
+- [IEP-5: Object Storage](#IEP-5-object-storage)
+  - [Table of Contents](#table-of-contents)
+  - [Summary](#summary)
+  - [Motivation](#motivation)
     - [Goals](#goals)
     - [Non-Goals](#non-goals)
-- [Proposal](#proposal)
-- [Alternatives](#alternatives)
+  - [Proposal](#proposal)
+    - [Bucket](#bucket)
+    - [BucketClass](#bucketclass)
+    - [BucketPool](#bucketpool)
+  - [Alternatives](#alternatives)
 
 ## Summary
 Object storage builds the basis for many cloud applications. An Object Storage provides a simplified object 
diff --git a/docs/proposals/06-storage-encryption.md b/docs/proposals/06-storage-encryption.md
index fdaac20ff..784cea3cf 100644
--- a/docs/proposals/06-storage-encryption.md
+++ b/docs/proposals/06-storage-encryption.md
@@ -1,7 +1,7 @@
 ---
 title: Storage Encryption
 
-oep-number: 6
+iep-number: 6
 
 creation-date: 2023-01-03
 
@@ -20,15 +20,17 @@ reviewers:
 
 ---
 
-# OEP-6: Storage Encryption
+# IEP-6: Storage Encryption
 
 ## Table of Contents
 
-- [Summary](#summary)
-- [Motivation](#motivation)
+- [IEP-6: Storage Encryption](#IEP-6-storage-encryption)
+  - [Table of Contents](#table-of-contents)
+  - [Summary](#summary)
+  - [Motivation](#motivation)
     - [Goals](#goals)
-    - [Non-Goals](#Non-Goals)
-- [Proposal](#proposal)
+    - [Non-Goals](#non-goals)
+  - [Proposal](#proposal)
 
 ## Summary
 One of the important feature of Cloud Native IaaS is to provide secure storage. This proposal focuses on providing option to enable encryption for individual ironcore Volume.
diff --git a/docs/proposals/07-quota.md b/docs/proposals/07-quota.md
index e61e72f0c..6d4b6c4e5 100644
--- a/docs/proposals/07-quota.md
+++ b/docs/proposals/07-quota.md
@@ -1,7 +1,7 @@
 ---
 title: Quota
 
-oep-number: 7
+iep-number: 7
 
 creation-date: 2023-01-19
 
@@ -19,7 +19,7 @@ reviewers:
 
 ---
 
-# OEP-7: Quota
+# IEP-7: Quota
 
 ## Table of Contents
 
diff --git a/docs/proposals/08-internal-load-balancer.md b/docs/proposals/08-internal-load-balancer.md
index 12aa34f37..97873dbde 100644
--- a/docs/proposals/08-internal-load-balancer.md
+++ b/docs/proposals/08-internal-load-balancer.md
@@ -1,7 +1,7 @@
 ---
 title: OEP Title
 
-oep-number: 8
+iep-number: 8
 
 creation-date: 2023-03-16
 
@@ -14,16 +14,18 @@ authors:
 
 ---
 
-# OEP-8: Internal Load Balancers
+# IEP-8: Internal Load Balancers
 
 ## Table of Contents
 
-- [Summary](#summary)
-- [Motivation](#motivation)
-  - [Goals](#goals)
-  - [Non-Goals](#non-goals)
-- [Proposal](#proposal)
-- [Alternatives](#alternatives)
+- [IEP-8: Internal Load Balancers](#IEP-8-internal-load-balancers)
+  - [Table of Contents](#table-of-contents)
+  - [Summary](#summary)
+  - [Motivation](#motivation)
+    - [Goals](#goals)
+    - [Non-Goals](#non-goals)
+  - [Proposal](#proposal)
+  - [Alternatives](#alternatives)
 
 ## Summary
 
diff --git a/docs/proposals/09-network-peering.md b/docs/proposals/09-network-peering.md
index f2832ebc2..240155782 100644
--- a/docs/proposals/09-network-peering.md
+++ b/docs/proposals/09-network-peering.md
@@ -1,7 +1,7 @@
 ---
 title: Network Peering
 
-oep-number: 9
+iep-number: 9
 
 creation-date: 2023-03-17
 
@@ -18,16 +18,18 @@ reviewers:
 
 ---
 
-# OEP-9: Network Peering
+# IEP-9: Network Peering
 
 ## Table of Contents
 
-- [Summary](#summary)
-- [Motivation](#motivation)
+- [IEP-9: Network Peering](#IEP-9-network-peering)
+  - [Table of Contents](#table-of-contents)
+  - [Summary](#summary)
+  - [Motivation](#motivation)
     - [Goals](#goals)
     - [Non-Goals](#non-goals)
-- [Proposal](#proposal)
-- [Alternatives](#alternatives)
+  - [Proposal](#proposal)
+  - [Alternatives](#alternatives)
 
 ## Summary
 
diff --git a/docs/proposals/10-network-policies.md b/docs/proposals/10-network-policies.md
index f4cc1dac1..b400baae4 100644
--- a/docs/proposals/10-network-policies.md
+++ b/docs/proposals/10-network-policies.md
@@ -1,7 +1,7 @@
 ---
 title: Network Policies
 
-oep-number: 10
+iep-number: 10
 
 creation-date: 2023-04-13
 
@@ -18,16 +18,18 @@ reviewers:
 
 ---
 
-# OEP-10: Network Policies
+# IEP-10: Network Policies
 
 ## Table of Contents
 
-- [Summary](#summary)
-- [Motivation](#motivation)
+- [IEP-10: Network Policies](#IEP-10-network-policies)
+  - [Table of Contents](#table-of-contents)
+  - [Summary](#summary)
+  - [Motivation](#motivation)
     - [Goals](#goals)
     - [Non-Goals](#non-goals)
-- [Proposal](#proposal)
-- [Alternatives](#alternatives)
+  - [Proposal](#proposal)
+  - [Alternatives](#alternatives)
 
 ## Summary
 
diff --git a/docs/proposals/11-public-prefix.md b/docs/proposals/11-public-prefix.md
new file mode 100644
index 000000000..1d021f66c
--- /dev/null
+++ b/docs/proposals/11-public-prefix.md
@@ -0,0 +1,155 @@
+---
+title: Refactor Prefix type for IPv6 usage
+
+iep-number: 11
+
+creation-date: 2024-02-25
+
+status: implementable
+
+authors:
+
+- "@afitzler"
+
+reviewers:
+
+- "@guvenc"
+- "@MalteJ"
+
+---
+
+# IEP-11: Refactor Prefix type for IPv6 usage
+
+## Table of Contents
+
+- [IEP-11: Public Prefix](#iep-11-public-prefix)
+  - [Table of Contents](#table-of-contents)
+  - [Summary](#summary)
+  - [Motivation](#motivation)
+    - [Goals](#goals)
+    - [Non-Goals](#non-goals)
+  - [Proposal](#proposal)
+  - [Alternatives](#alternatives)
+
+## Summary
+
+In an IPv6 environment, dynamically allocating IP prefixes is crucial for efficient address space management, ensuring 
+network security, and maintaining scalability. Allowing users to freely choose IPs and prefixes can lead to conflicts, 
+inefficient use of the address space, and security vulnerabilities. Furthermore, the use of local ranges contradicts 
+the design principles of IPv6, aimed at eliminating the need for such practices by providing a vast address space. 
+Therefore, we propose a new approach to how users can assign prefixes to `NetworkInterfaces`, as the current model, 
+introduced by the [Networking Integration IEP](01-networking-integration.md), does not align with these principles.
+
+## Motivation
+
+Currently, the `NetworkInterface` allows defining `IPs` and `Prefixes` for both IP families (IPv4 and IPv6) either by 
+providing a discrete value or by using an `EphemeralPrefixSource`. The `EphemeralPrefixSource` can be derived from an 
+IPv4 or IPv6 `Prefix`, allowing for the free selection of `NetworkInterface` IPs. In the IPv4 realm, it is common 
+practice to use a local, non-publicly routable IP range, with internet connectivity ensured via a `NATGateway` for 
+egress and a `LoadBalancer` for ingress traffic. However, this approach is not applicable to IPv6.
+Here we need to ensure that either a unique local IPv6 address is being used (`fd00::/8`) or an IP or `Prefix` is derived 
+from a parent `Prefix` object.
+
+### Goals
+
+- Control the unique distribution of IPs and `Prefixes`.
+- Assign IPs and `Prefixes` to `NetworkInterfaces` derived from a requested `Prefix`.
+- Disallow the direct assignment of non-unique local IPv6 (`fd00::/8`) addresses to `NetworkInterfaces` and internal `LoadBalancers`.
+- Implement non-disruptive changes for existing IPv4-based setups.
+
+### Non-Goals
+
+- Bring-your-own IPv6 public prefix support is not covered by this proposal. 
+
+## Proposal
+
+Restrict the implementation of the `Prefix` type to only allow `prefixLength` when using the IPv6 IP family. This can 
+be achieved by adding validation logic that prohibits the creation of a non-unique local IPv6 `Prefix` in the `spec.Prefix` 
+field. The allocation of a public routable IPv6 `Prefix` is ensured by a subsequent component and the effective `Prefix`
+is stored in the `Status` of the `Prefix` resource.
+
+The further division of the `Prefix` into sub-allocations via  `spec.parentPrefix` reference allows the user to create 
+`Prefixes` derived from the parent.
+
+For IPv4, no change is needed as we will continue with the existing API contract.
+
+Below is an example of a `Prefix` resource requesting a prefix of size 56:
+
+```yaml
+apiVersion: ipam.ironcore.dev/v1alpha1
+kind: Prefix
+metadata:
+  namespace: default
+  name: my-prefix
+spec:
+  ipFamily: IPv6
+  prefixLength: 56
+status:
+  phase: Pending # Becomes Allocated once the prefix length has been assigned.
+  prefix: ffff::/56 # The effective assigned prefix.
+```
+
+Here is an example of how a subsequent Prefix, which derives its address from a parent prefix, is defined:
+
+```yaml
+apiVersion: ipam.ironcore.dev/v1alpha1
+kind: Prefix
+metadata:
+  namespace: default
+  name: my-sub-prefix
+spec:
+  ipFamily: IPv6
+  parentPrefix:
+    name: my-prefix
+  prefixLength: 128
+status:
+  phase: Pending # Becomes Allocated once the prefix length has been assigned.
+  prefix: ffff::dddd/128 # The effective assigned prefix.
+```
+
+In the same manner a validation on the `NetworkInterface` resource will ensure that `spec.IPs` only contain unique local
+IPv6 addresses. Alternatively, an ephemeral `Prefix` with a parent relationship to the initial requested `Prefix` ensures 
+a unique public IPv6 address allocation for a `NetworkInterface`.
+
+```yaml
+apiVersion: networking.ironcore.dev/v1alpha1
+kind: NetworkInterface
+metadata:
+  namespace: default
+  name: my-nic
+spec:
+  ips:
+    ephemeral:
+      prefixTemplate:
+        spec:
+          parentRef:
+            name: my-prefix
+```
+
+Here the `prefixTemplate` validation will ensure that no non-unique local IPv6 addresses are assigned.
+
+A similar behaviour is ensured for the internal `LoadBalancer` case. The example below illustrates how an internal
+`LoadBalancer` can request a unique IPv6 address from a parent `Prefix`.
+
+```yaml
+apiVersion: networking.ironcore.dev/v1alpha1
+kind: LoadBalancer
+metadata:
+  namespace: default
+  name: my-lb
+spec:
+  type: Internal
+  ipFamilies:
+    - IPv6
+  ips:
+    - ephemeral:
+        prefixTemplate:
+          spec:
+            parentPrefix:
+              name: my-prefix
+```
+
+## Alternatives
+
+An alternative to the proposed solution would be to define a dedicated API type acting as a Prefix request for a
+specified IPv6 prefix length.