The Dynamic Host Configuration Protocol for IPv4 (DHCPv4) has been extended with a Leasequery capability that allows a requestor to request information about bindings (RFC 4388). That mechanism is limited to queries for individual bindings. In some situations, individual binding queries may not be efficient, or even possible. In addition, continuous update of an external requestor with Leasequery data is sometimes desired. This document expands on the DHCPv4 Leasequery protocol, and allows for active transfer of near real-time DHCPv4 binding information data via TCP. This document updates RFC 6926, DHCPv4 Bulk Leasequery.

Named Data Networking (NDN) routers can cache previously forwarded Data packets, and those can be reused when a matching Interest packet arrives. Unlike traditional IP routers and HTTP caches that exist as separate devices, designing a scalable NDN router is a new challenge because it should perform fast forwarding and massive-scale caching at the same time. This paper proposes a design of an NDN router with unique forwarding and caching mechanisms featuring terabyte-scale caching with solid-state drives (SSD) while still forwarding packets at line speed.

Named Data Networking (NDN) is an information-centric networking architecture that has recently attracted significant attention. At first glance NDN's pure pull-based communication model seems to match the request-reply mechanics of HTTP/Web interactions. In reality, modern Web communication patterns involve passing client-side information and/or application state in requests. As we attempt to apply these communication patterns to NDN, we find that it is not immediately clear how to use NDN effectively. In this paper, we examine multiple diverse approaches to running modern Web-like applications over the NDN communication architecture, discussing advantages and drawbacks of each of the proposed approaches. Our primary goal is to start a focused discussion of how NDN can support modern Web communication patterns effectively.

Named data networking (NDN) is a new networking paradigm using named data instead of named hosts for communication. Implementation of scalable NDN packet forwarding remains a challenge because NDN requires fast variable-length hierarchical name-based lookup, per-packet data plane state update, and large-scale forwarding tables. We have designed and implemented an NDN data plane with a software forwarding engine on an Intel Xeon-based line card in a Cisco ASR9000 router. In order to achieve high-speed forwarding, our design features (1) name lookup via hash tables with fast collision-resistant hash computation, (2) an efficient and secure FIB lookup algorithm that provides good average and bounded worst-case FIB lookup time, (3) PIT partitioning that enables linear multi-core speedup, and (4) an optimized data structure and software prefetching to maximize data cache utilization. In this demonstration, we showcase our NDN router implementation on the ASR9000 and demonstrate that it can forward real NDN traffic at 20Gbps or higher.

This document defines a new Relay Agent Identifier sub-option for the Dynamic Host Configuration Protocol (DHCP) Relay Agent Information option.The sub-option carries a value that uniquely identifies the relay agent device within the administrative domain.The value is normally administratively configured in the relay agent.The suboption allows a DHCP relay agent to include the identifier in the DHCP messages it sends.

The Dynamic Host Configuration Protocol for IPv4 (DHCPv4) has been extended with a Leasequery capability that allows a client to request information about DHCPv4 bindings. That mechanism is limited to queries for individual bindings. In some situations individual binding queries may not be efficient, or even possible. This document expands on the DHCPv4 Leasequery protocol to allow for bulk transfer of DHCPv4 address binding data via TCP.

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.

The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) has been extended with a Leasequery capability that allows a client to request information about DHCPv6 bindings. That mechanism is limited to queries for individual bindings. In some situations individual binding queries may not be efficient, or even possible. This document expands on the Leasequery protocol, adding new query types and allowing for bulk transfer of DHCPv6 binding data via TCP. [STANDARDS-TRACK]

This memo defines a new suboption of the DHCP relay information option that allows the DHCP relay to specify a new value for the Server Identifier option, which is inserted by the DHCP Server.This allows the DHCP relay to act as the actual DHCP server such that RENEW DHCPREQUESTs will come to the relay instead of going to the server directly.This gives the relay the opportunity to include the Relay Agent option with appropriate suboptions even on DHCP RENEW messages.

L'invention concerne la creation d'une association entre une adresse de source et un ou plusieurs roles d'un utilisateur accedant au reseau, ainsi que la distribution de cette liaison a un noeud de filtrage. L'adresse de source est affectee au dispositif. Cette association peut etre generee par un ou plusieurs noeuds sur un trajet d'entree utilise pendant l'authentification de l'utilisateur. L'association peut etre distribuee au noeud filtrant a la demande ou sans demande emanant de ce noeud. En reponse a la determination que l'utilisateur est associe a une nouvelle adresse de source, une nouvelle association est generee, de maniere a associer cette nouvelle adresse de source au(x) role(s) de l'utilisateur. Cette nouvelle association est distribuee au noeud filtrant. L'invention concerne, dans un autre aspect, un procede de mise en application d'une police de securite basee sur la reconnaissance des roles au niveau d'un noeud filtrant au moyen d'associations d'adresses de source et de roles.

This memo defines a new suboption of the Dynamic Host Configuration Protocol (DHCP) relay agent information option that allows the DHCP relay to specify flags for the forwarded packet. One flag is defined to indicate whether the DHCP relay received the packet via a unicast or broadcast packet. This information may be used by the DHCP server to better serve clients based on whether their request was originally broadcast or unicast. [STANDARDS-TRACK]

It is possible for Dynamic Host Configuration Protocol (DHCP) clients to attempt to update the same DNS Fully Qualified Domain Name (FQDN) or to update a DNS FQDN that has been added to the DNS for another purpose as they obtain DHCP leases. Whether the DHCP server or the clients themselves perform the DNS updates, conflicts can arise. To resolve such conflicts, RFC 4703 proposes storing client identifiers in the DNS to unambiguously associate domain names with the DHCP clients to which they refer. This memo defines a distinct Resource Record (RR) type for this purpose for use by DHCP clients and servers: the DHCID RR. [STANDARDS-TRACK]

The Dynamic Host Configuration Protocol (DHCP) provides a mechanism for host configuration that includes dynamic assignment of IP addresses and fully qualified domain names. To maintain accurate name- to-IP-address and IP-address-to-name mappings in the DNS, these dynamically assigned addresses and fully qualified domain names (FQDNs) require updates to the DNS. This document identifies situations in which conflicts in the use of fully qualified domain names may arise among DHCP clients and servers, and it describes a strategy for the use of the DHCID DNS resource record (RR) in resolving those conflicts. [STANDARDS-TRACK]

The Dynamic Host Configuration Protocol (DHCP) Relay Agent Information Option (RFC 3046) conveys information between a DHCP Relay Agent and a DHCP server. This specification defines an authentication suboption for that option, containing a keyed hash in its payload. The suboption supports data integrity and replay protection for relayed DHCP messages. [STANDARDS-TRACK]