]>

brendon@drewnet.com.au

Internet This document defines a DHCPv4 option that conveys one or more IPv4 prefixes that are routed toward a DHCP client independently of the client's on-link DHCP-assigned IPv4 address and default-router configuration. The option is intended for requesting routers whose upstream attachment address is distinct from IPv4 prefix space routed toward them. Examples include access networks in which a customer router receives a private-use address or Shared Address Space attachment address while one or more additional public or private IPv4 prefixes are routed toward that router. This document does not define how the upstream network establishes the route, does not require Network Address Translation (NAT), and does not specify how a client uses, assigns, translates, or delegates an advertised prefix after receipt.

Introduction DHCPv4 provides a mechanism for assigning an IPv4 address and other configuration information to a client. In many access networks, however, the address used by a router to attach to the upstream network is not necessarily the same address space that the provider routes toward that router. For example, a requesting router might receive:

In this example, 203.0.113.42/32 is not on-link on the upstream interface. The upstream network has independently arranged for traffic destined to 203.0.113.42/32 to be forwarded toward the requesting router. This separation can be useful where globally unique IPv4 address space is scarce. A provider can use shared, private, or otherwise suitable addressing for subscriber attachment while assigning globally routable IPv4 space only to subscribers that require it. It also permits the routed resource to be a subnet, rather than requiring the customer's globally routable address space to form part of the access-link addressing plan. DHCPv4 presently has mechanisms for telling a client where to send traffic. For example, the Classless Static Route Option communicates destination prefixes and next hops that a client should install. The mechanism defined here communicates the inverse relationship: it tells a requesting router that specified prefixes are routed toward that router by the upstream network. Cisco's Subnet Allocation Option, documented in , also describes allocation of IPv4 subnets using DHCPv4. That protocol contains request, allocation, renewal, release, deprecation, hierarchy, and usage-reporting semantics. The option defined by this document is deliberately narrower. It does not allocate a subnet and does not define an independent subnet lease. It only conveys routing information associated with the client's existing DHCPv4 lease. DHCPv6 Prefix Delegation, now specified by , demonstrates a related architectural property in IPv6: a requesting router can use one form of upstream attachment while prefixes used beyond that attachment are separately communicated. The option defined here is not an IPv4 port of DHCPv6 Prefix Delegation. It has no IA_PD-style state machine, independent prefix lifetimes, prefix hints, or delegation negotiation. The purpose of this document is therefore limited to a missing DHCPv4 configuration primitive:

• Inform a requesting router of one or more IPv4 prefixes that the upstream network currently routes toward it, independently of the client's on-link IPv4 address.

Requirements Language The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Terminology This document uses the following terms:

Client

A DHCPv4 client implementing this option. In the context of this document, the client is normally a router.

Requesting Router

A DHCPv4 client that receives routed-prefix information and is capable of receiving traffic for those prefixes from its upstream network.

Attachment Address

The IPv4 address assigned to the client by ordinary DHCPv4 mechanisms for use on the upstream link.

Routed Prefix

An IPv4 network prefix that the upstream network represents as being routed toward the requesting router. A Routed Prefix is not, solely by virtue of this option, an on-link prefix on the upstream interface.

Upstream Network

The network providing the DHCPv4 service and routing the advertised Routed Prefixes toward the requesting router.

Scope This document defines only the communication of Routed Prefix information. It does not define: how the upstream network creates or distributes the route; how a server selects which prefixes are associated with a client; how the client assigns a prefix to an interface or downstream link; how the client performs NAT, port translation, proxying, or service binding; how the client further delegates a prefix; firewall policy; source-address authorization; or provider accounting, subscriber management, or routing policy. A client MAY use a received Routed Prefix for NAT, local address assignment, downstream routing, service binding, or another purpose, subject to local policy. No such behavior is implied by receipt of the option.

Routed IPv4 Prefix Option

Option Format The DHCPv4 Routed IPv4 Prefix Option is encoded according to the DHCP option format defined in and has the following format:

The option contains no next-hop field. The next-hop relationship is already established by the client's ordinary DHCPv4 configuration and the upstream network's routing state. The Prefix List in an individual option instance can be a fragment of the complete Prefix List. When multiple instances of this option occur in a DHCP message, they MUST be concatenated before the Prefix List is validated or parsed, as specified in . The option contains no independent lifetime field. The validity of the information is bound to the DHCPv4 lease as described in .

Routed Prefix Descriptor Each Routed Prefix is encoded using a compact prefix representation similar to the destination-descriptor encoding in :

Prefix Length is an unsigned integer from 1 through 32 specifying the number of significant bits in the IPv4 prefix. A value of 0 is invalid and MUST NOT be sent or accepted. A default-route prefix is not suitable for this option because it would normally create a routing loop between the upstream network and the requesting router. Prefix Bytes contains ceil(Prefix Length / 8) octets. Only the significant octets of the IPv4 prefix are carried. The number of prefix octets is therefore: Prefix Length Prefix Bytes 1-8 1 9-16 2 17-24 3 25-32 4 When the prefix length is not an integer multiple of eight, any bits in the final octet that lie outside the prefix length MUST be zero when sent. A receiver MUST mask any such bits before constructing the prefix. For example: Routed Prefix Encoded Descriptor 10.0.0.0/8 08 0a 192.0.2.0/24 18 c0 00 02 198.51.100.64/27 1b c6 33 64 40 203.0.113.42/32 20 cb 00 71 2a

Multiple Prefixes Multiple Routed Prefix descriptors are concatenated directly in the Prefix List. For example, the following logical value:

is encoded as three consecutive descriptors. A client MUST process each descriptor after validating the complete concatenated Prefix List. A server MUST NOT include the same prefix more than once in the effective option value.

Long Option Encoding The Routed IPv4 Prefix Option is a concatenation-requiring option in the sense of . Clients implementing this option and servers sending this option MUST implement DHCPv4 option splitting and concatenation as specified by . After concatenation, the resulting octet sequence is parsed as one Prefix List.

DHCP Client Behavior A client supporting the Routed IPv4 Prefix Option MUST include the option code in the Parameter Request List option in every DHCPREQUEST message. It SHOULD also include the code in any other DHCP message that carries a Parameter Request List option. A client receiving this option in a DHCPACK MUST interpret each advertised prefix as a statement from the DHCP server that the upstream network intends traffic for that prefix to be routed toward the client for the validity period described in . A client: MUST NOT infer that an advertised Routed Prefix is on-link on its upstream interface solely because it appears in this option; MUST NOT alter its DHCP-assigned Attachment Address, subnet mask, or Router option solely because this option is present; MUST NOT treat receipt of the option as proof of authorization to originate packets using an address from an advertised prefix; and MAY make the prefix available to local routing, address assignment, NAT, service-binding, or downstream configuration mechanisms according to local policy. A client that does not implement this option ignores it in accordance with normal DHCPv4 option processing. A malformed option MUST be ignored in its entirety. An option is malformed if, after RFC 3396 concatenation, its Prefix List is empty, any prefix descriptor is truncated, a Prefix Length is 0 or greater than 32, or the option otherwise cannot be unambiguously parsed.

DHCP Server Behavior A server MUST send this option only when the client requested it in the Parameter Request List option of the corresponding client message. A server MAY include it in a DHCPOFFER when the client requested it, to indicate prefixes that the server intends to associate with a lease. The definitive Routed Prefix set is the set contained in the DHCPACK that establishes or renews the lease. A server sending this option: MUST include only prefixes that its provisioning and routing system intends to route toward the client; MUST establish the corresponding routing state before sending the DHCPACK containing the option; MUST include the complete current Routed Prefix set associated with the lease in each DHCPACK in which the option is sent; and MUST encode prefixes in canonical form as described in this document. The mechanism by which the DHCP server learns the applicable Routed Prefix set is outside the scope of this document. It may derive the set from static configuration, subscriber provisioning, RADIUS, an IPAM system, a routing controller, or another source.

Lease Lifetime, Renewal, and Withdrawal A Routed Prefix conveyed by this option is valid only in association with the DHCPv4 lease for which it was acknowledged. Unless another standards-track specification explicitly defines different semantics for a future extension, a Routed Prefix has no lifetime independent of the DHCPv4 lease. When a client receives a DHCPACK containing this option, the option value represents the server's current Routed Prefix set for that lease. If a prefix that was present in the previously acknowledged set is absent from a subsequent DHCPACK that contains this option, the client MUST cease treating that prefix as currently routed toward it. If the DHCPv4 lease expires or is invalidated, the client MUST cease treating all Routed Prefixes learned through that lease as currently routed toward it. A DHCP server that needs a client to renew before the normal T1/T2 timers MAY use existing DHCPv4 mechanisms such as DHCPFORCERENEW , where operationally appropriate.

Absence of the Option If a client requested this option in the DHCPREQUEST and the acknowledging server had previously supplied the option for the same lease, omission of the option from the subsequent DHCPACK MUST be treated as withdrawal of all previously learned Routed Prefixes. Thus, an empty response to a request for this option means that the server no longer represents any additional prefixes as routed toward the client. A client MUST also withdraw the prefixes when the associated lease is lost, expires, or is replaced by a lease from another server.

Relationship to Existing DHCP Routing Options The Router option and the Classless Static Route Option describe routes the DHCP client should use to reach destinations. This option describes prefixes for which the direction of reachability is reversed:

destination prefix via specified next hop Routed IPv4 Prefix Option: upstream network -----> advertised prefix routed toward DHCP client ]]>

The two options therefore carry different information and MAY appear in the same lease. Receipt of the Routed IPv4 Prefix Option MUST NOT change the processing rules for the Router or Classless Static Route options.

Relationship to RFC 6656 Subnet Allocation documents Cisco Systems' Subnet Allocation Option (option 220). That option can request and allocate IPv4 subnets and has specific mechanisms for subnet lease lifetimes, renewals, releases, deprecation, hierarchical allocation, and usage statistics. The option specified by this document intentionally does not reproduce that protocol. In particular: the client does not request a particular prefix or prefix length using this option; the server does not allocate a prefix as a separately leased resource through this option; there are no per-prefix renewal or release transactions; there are no usage statistics; there is no hierarchical-allocation flag; and the advertised set is simply information associated with the client's ordinary DHCPv4 lease. This narrower model is intended for deployments in which the routing or subscriber provisioning system already determines which prefixes are routed toward a client and DHCPv4 is used to communicate that existing state to the requesting router.

Relationship to DHCPv6 Prefix Delegation DHCPv6 includes Prefix Delegation as specified by . Prefix Delegation allows a DHCPv6 server to delegate IPv6 prefixes to a client using dedicated identity associations and prefix lifetimes. The mechanism specified here shares one useful architectural property with DHCPv6 Prefix Delegation: the prefix used beyond a requesting router can be distinct from the address used by that router for its upstream attachment. However, this specification does not reproduce DHCPv6-PD semantics for IPv4. There is no separate allocation transaction, no prefix-length hint, no IA_PD equivalent, and no preferred/valid lifetime carried per prefix. This option only communicates prefixes that the server's upstream provisioning system already considers routed toward the requesting router. This specification is not intended as an alternative to IPv6 deployment.

Examples The addresses used in these examples are documentation addresses and are not intended for deployment.

Shared Attachment Address with a Routed Public /32 A provider uses Shared Address Space for subscriber attachment:

The provider's routing system has arranged:

subscriber attachment ]]>

The DHCP server includes:

The requesting router continues to use 100.64.20.1 as its upstream default router. The option does not specify whether the requesting router assigns 203.0.113.42 locally, uses it as a NAT address, routes it to another device, or binds a service to it.

Routed Public Subnet A business subscriber has:

The requesting router receives the /29 through the Routed IPv4 Prefix Option. The /29 is not considered on-link on the upstream interface solely as a result of receiving the option. The customer may route the /29 internally according to local policy.

Multiple Routed Prefixes A requesting router receives:

The first two prefixes might be globally routable resources and the third might be private routed space. The option itself makes no distinction between public and private IPv4 prefixes.

Prefix Withdrawal on Renewal Initial DHCPACK:

Later DHCPACK:

The client MUST cease treating 198.51.100.64/29 as routed toward it. The upstream network remains responsible for ensuring that revoked or unassigned source addresses cannot be used contrary to network policy.

Backwards Compatibility DHCPv4 clients that do not recognize the option ignore it under normal DHCP option processing. The option does not change the semantics of the client's assigned IPv4 address, subnet mask, Router option, Classless Static Route Option, or other existing DHCPv4 options. A server can therefore deploy this option for supporting requesting routers without changing ordinary DHCPv4 behavior for clients that do not implement it.

Operational Considerations

Routing State The DHCP server's advertisement of a Routed Prefix does not create the upstream route. Operators MUST ensure that the corresponding routing state exists before the DHCP server sends the DHCPACK containing the Routed Prefix. Likewise, when a prefix is withdrawn, operators SHOULD coordinate withdrawal of routing state and subscriber authorization in a manner that avoids unintended reassignment or traffic delivery.

Address Conservation One motivation for the option is to allow access-link addressing to be decoupled from routed customer IPv4 resources. For example, a provider may maintain a large subscriber attachment network using shared or private address space while allocating individual globally routable /32 addresses or larger prefixes only where required. This document does not prescribe such an architecture and does not require Carrier-Grade NAT.

Client Use of Routed Prefixes Implementations are expected to expose received Routed Prefixes to appropriate local subsystems, but this document deliberately does not mandate one use model. Possible uses include: source NAT using an advertised /32; routing a larger prefix to a downstream interface; assigning an address from the prefix to a loopback or service interface; or making the prefix available to another local network-management component. These are examples only.

Security Considerations This option conveys routing information. It is not an authorization credential. A client MUST NOT treat possession or receipt of a Routed Prefix as cryptographic or administrative proof that the client is authorized to originate packets using addresses from that prefix. The upstream network remains responsible for source-address validation and subscriber policy. Techniques such as ingress filtering described by BCP 38 , access-layer source validation, or equivalent provider controls can be used as appropriate. The security considerations of DHCPv4 apply. A forged or malicious DHCP response containing this option could cause a client to believe that prefixes are routed toward it when they are not. This may cause denial of service, accidental address conflicts, incorrect NAT behavior, or exposure of services. Where DHCP authentication is deployed, provides mechanisms for authenticating DHCP messages. Deployments may also rely on lower-layer controls, DHCP snooping, trusted access links, or other mechanisms appropriate to their environment. A server MUST NOT advertise a prefix to a client merely because the client claims or requests use of that prefix through some unrelated mechanism. The advertised set must originate from trusted provisioning or routing policy. A client SHOULD remove withdrawn prefix state promptly. However, upstream enforcement MUST NOT assume that every client will behave correctly after withdrawal.

IANA Considerations IANA is requested to assign one DHCPv4 option code from the "BOOTP Vendor Extensions and DHCP Options" registry for: Value Name Data Length Meaning TBD1 Routed IPv4 Prefix N IPv4 prefixes routed toward the DHCP client The registration should reference this document. The option is a concatenation-requiring option as specified by .

Acknowledgements The author would like to thank the DHCP and operational networking communities for prior work on DHCPv4 routing options, IPv4 subnet allocation, and DHCPv6 Prefix Delegation that informed this proposal.

The Dynamic Host Configuration Protocol (DHCP) provides a framework for passing configuration information to hosts on a TCPIP network. DHCP is based on the Bootstrap Protocol (BOOTP), adding the capability of automatic allocation of reusable network addresses and additional configuration options. [STANDARDS-TRACK] This document specifies the current set of DHCP options. Future options will be specified in separate RFCs. The current list of valid options is also available in ftp://ftp.isi.edu/in-notes/iana/assignments. [STANDARDS-TRACK] This document specifies the processing rules for DHCPv4 options that appear multiple times in the same message. Multiple instances of the same option are generated when an option exceeds 255 octets in size (the maximum size of a single option) or when an option needs to be split apart in order to take advantage of DHCP option overloading. When multiple instances of the same option appear in the options, file and/or sname fields in a DHCP packet, the contents of these options are concatenated together to form a single option prior to processing. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document describes address allocation for private internets. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This paper discusses a simple, effective, and straightforward method for using ingress traffic filtering to prohibit DoS (Denial of Service) attacks which use forged IP addresses to be propagated from 'behind' an Internet Service Provider's (ISP) aggregation point. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document defines a new Dynamic Host Configuration Protocol (DHCP) option through which authorization tickets can be easily generated and newly attached hosts with proper authorization can be automatically configured from an authenticated DHCP server. [STANDARDS-TRACK] This document defines extensions to DHCP (Dynamic Host Configuration Protocol) to allow dynamic reconfiguration of a single host triggered by the DHCP server (e.g., a new IP address and/or local configuration parameters). [STANDARDS-TRACK] This document defines a new Dynamic Host Configuration Protocol (DHCP) option which is passed from the DHCP Server to the DHCP Client to configure a list of static routes in the client. The network destinations in these routes are classless - each routing table entry includes a subnet mask. [STANDARDS-TRACK] This document requests the allocation of an IPv4 /10 address block to be used as Shared Address Space to accommodate the needs of Carrier- Grade NAT (CGN) devices. It is anticipated that Service Providers will use this Shared Address Space to number the interfaces that connect CGN devices to Customer Premises Equipment (CPE). Shared Address Space is distinct from RFC 1918 private address space because it is intended for use on Service Provider networks. However, it may be used in a manner similar to RFC 1918 private address space on routing equipment that is able to do address translation across router interfaces when the addresses are identical on two different interfaces. Details are provided in the text of this document. This document details the allocation of an additional special-use IPv4 address block and updates RFC 5735. This memo documents an Internet Best Current Practice. This memo documents a DHCPv4 option that currently exists and was previously privately defined for the operation and usage of the Cisco Systems' Subnet Allocation Option for DHCPv4. The option is passed between the DHCPv4 Client and the DHCPv4 Server to request dynamic allocation of a subnet, give specifications of the subnet(s) allocated, and report usage statistics. This memo documents the current usage of the option in agreement with RFC 3942, which declares that any preexisting usages of option numbers in the range 128-223 should be documented and that the working group will try to officially assign those numbers to those options. This document is not an Internet Standards Track specification; it is published for informational purposes. This document specifies the Dynamic Host Configuration Protocol for IPv6 (DHCPv6), an extensible mechanism for configuring nodes with network configuration parameters, IP addresses, and prefixes. Parameters can be provided statelessly or in combination with stateful assignment of one or more IPv6 addresses and/or IPv6 prefixes. DHCPv6 can operate either in place of or in addition to stateless address autoconfiguration (SLAAC). This document obsoletes RFC 8415. It incorporates verified errata and obsoletes the assignment of temporary addresses (the IA_TA option) and the server unicast capability (the Server Unicast option and UseMulticast status code).

Design Notes for Revision -00 This appendix is non-normative and is expected to be removed or revised before publication. Items for early working-group discussion include: Whether the Parameter Request List requirement is sufficient client capability signaling. Whether the compact RFC 3442-style prefix encoding is preferable to fixed-width {IPv4 address, prefix length} tuples. Whether additional text is required to distinguish this mechanism from the Cisco Subnet Allocation Option in RFC 6656. Whether the DHC working group prefers another name, such as "DHCPv4 Routed Prefix Information Option".