| |
| RFC 8500 | IS-IS Routing with Reverse Metric |
| |
| Authors: | N. Shen, S. Amante, M. Abrahamsson. |
| Date: | February 2019 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8500 |
|
This document describes a mechanism to allow IS-IS routing to quickly and accurately shift traffic away from either a point-to-point or multi-access LAN interface during network maintenance or other operational events. This is accomplished by signaling adjacent IS-IS neighbors with a higher reverse metric, i.e., the metric towards the signaling IS-IS router. |
|
| |
| RFC 8501 | Reverse DNS in IPv6 for Internet Service Providers |
| |
| Authors: | L. Howard. |
| Date: | November 2018 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8501 |
|
In IPv4, Internet Service Providers (ISPs) commonly provideIN-ADDR.ARPA information for their customers by prepopulating the zone with one PTR record for every available address. This practice does not scale in IPv6. This document analyzes different approaches and considerations for ISPs in managing the IP6.ARPA zone. |
|
| |
| RFC 8502 | L2L3 VPN Multicast MIB |
| |
| Authors: | Z. Zhang, H. Tsunoda. |
| Date: | December 2018 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8502 |
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it describes two MIB modules that will be used by other MIB modules for monitoring and/or configuring Layer 2 and Layer3 Virtual Private Networks that support multicast. |
|
| |
| RFC 8503 | BGP/MPLS Layer 3 VPN Multicast Management Information Base |
| |
| Authors: | H. Tsunoda. |
| Date: | December 2018 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8503 |
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it describes managed objects to configure and/or monitor Multicast communication over IP Virtual Private Networks(VPNs) supported by the Multiprotocol Label Switching/Border GatewayProtocol (MPLS/BGP) on a Provider Edge (PE) router. |
|
| |
| RFC 8504 | IPv6 Node Requirements |
| |
|
|
This document defines requirements for IPv6 nodes. It is expected that IPv6 will be deployed in a wide range of devices and situations.Specifying the requirements for IPv6 nodes allows IPv6 to function well and interoperate in a large number of situations and deployments.
This document obsoletes RFC 6434, and in turn RFC 4294. |
|
| |
| RFC 8505 | Registration Extensions for IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Neighbor Discovery |
| |
|
|
This specification updates RFC 6775 -- the Low-Power WirelessPersonal Area Network (6LoWPAN) Neighbor Discovery specification -- to clarify the role of the protocol as a registration technique and simplify the registration operation in 6LoWPAN routers, as well as to provide enhancements to the registration capabilities and mobility detection for different network topologies, including the RoutingRegistrars performing routing for host routes and/or proxy NeighborDiscovery in a low-power network. |
|
| |
| RFC 8506 | Diameter Credit-Control Application |
| |
| Authors: | L. Bertz, Ed., D. Dolson, Ed., Y. Lifshitz, Ed.. |
| Date: | March 2019 |
| Formats: | txt html json |
| Obsoletes: | RFC 4006 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8506 |
|
This document specifies a Diameter application that can be used to implement real-time credit-control for a variety of end-user services such as network access, Session Initiation Protocol (SIP) services, messaging services, and download services. The Diameter Credit-Control application as defined in this document obsoletes RFC 4006, and it must be supported by all new Diameter Credit-Control application implementations. |
|
| |
| RFC 8507 | Simple Internet Protocol (SIP) Specification |
| |
| Authors: | S. Deering, R. Hinden, Ed.. |
| Date: | December 2018 |
| Formats: | txt html json |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 8507 |
|
This document is published for the historical record. The SimpleInternet Protocol was the basis for one of the candidates for theIETF's Next Generation (IPng) work that became IPv6.
The publication date of the original Internet-Draft was November 10,1992. It is presented here substantially unchanged and is neither a complete document nor intended to be implementable.
The paragraph that follows is the Abstract from the original draft.
This document specifies a new version of IP called SIP, the SimpleInternet Protocol. It also describes the changes needed to ICMP,IGMP, and transport protocols such as TCP and UDP, in order to work with SIP. A companion document [SIP-ADDR] describes the addressing and routing aspects of SIP, including issues of auto-configuration, host and subnet mobility, and multicast. |
|
| |
| RFC 8508 | IMAP REPLACE Extension |
| |
| Authors: | S. Brandt. |
| Date: | January 2019 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8508 |
|
This document defines an IMAP extension that can be used to replace an existing message in a message store with a new message. Message replacement is a common operation for clients that automatically save drafts or notes as a user composes them. |
|
| |
| RFC 8509 | A Root Key Trust Anchor Sentinel for DNSSEC |
| |
| Authors: | G. Huston, J. Damas, W. Kumari. |
| Date: | December 2018 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8509 |
|
The DNS Security Extensions (DNSSEC) were developed to provide origin authentication and integrity protection for DNS data by using digital signatures. These digital signatures can be verified by building a chain of trust starting from a trust anchor and proceeding down to a particular node in the DNS. This document specifies a mechanism that will allow an end user and third parties to determine the trusted key state for the root key of the resolvers that handle that user's DNS queries. Note that this method is only applicable for determining which keys are in the trust store for the root key. |
|
| |
| RFC 8510 | OSPF Link-Local Signaling (LLS) Extensions for Local Interface ID Advertisement |
| |
| Authors: | P. Psenak, Ed., K. Talaulikar, W. Henderickx, P. Pillay-Esnault. |
| Date: | January 2019 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8510 |
|
Every OSPF interface is assigned an Interface ID that uniquely identifies the interface on the router. In some cases, it is useful to know the assigned Interface ID on the remote side of the adjacency(Remote Interface ID).
This document describes the extensions to OSPF link-local signaling(LLS) to advertise the Local Interface ID. |
|
| |
| RFC 8511 | TCP Alternative Backoff with ECN (ABE) |
| |
| Authors: | N. Khademi, M. Welzl, G. Armitage, G. Fairhurst. |
| Date: | December 2018 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 8511 |
|
Active Queue Management (AQM) mechanisms allow for burst tolerance while enforcing short queues to minimise the time that packets spend enqueued at a bottleneck. This can cause noticeable performance degradation for TCP connections traversing such a bottleneck, especially if there are only a few flows or their bandwidth-delay product (BDP) is large. The reception of a Congestion Experienced(CE) Explicit Congestion Notification (ECN) mark indicates that anAQM mechanism is used at the bottleneck, and the bottleneck network queue is therefore likely to be short. Feedback of this signal allows the TCP sender-side ECN reaction in congestion avoidance to reduce the Congestion Window (cwnd) by a smaller amount than the congestion control algorithm's reaction to inferred packet loss.Therefore, this specification defines an experimental change to theTCP reaction specified in RFC 3168, as permitted by RFC 8311. |
|
| |
| RFC 8512 | A YANG Module for Network Address Translation (NAT) and Network Prefix Translation (NPT) |
| |
| Authors: | M. Boucadair, Ed., S. Sivakumar, C. Jacquenet, S. Vinapamula, Q. Wu. |
| Date: | January 2019 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8512 |
|
This document defines a YANG module for the Network AddressTranslation (NAT) function.
Network Address Translation from IPv4 to IPv4 (NAT44), NetworkAddress and Protocol Translation from IPv6 Clients to IPv4 Servers(NAT64), customer-side translator (CLAT), Stateless IP/ICMPTranslation (SIIT), Explicit Address Mappings (EAM) for SIIT,IPv6-to-IPv6 Network Prefix Translation (NPTv6), and Destination NAT are covered in this document. |
|
| |
| RFC 8513 | A YANG Data Model for Dual-Stack Lite (DS-Lite) |
| |
| Authors: | M. Boucadair, C. Jacquenet, S. Sivakumar. |
| Date: | January 2019 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8513 |
|
This document defines a YANG module for the Dual-Stack Lite (DS-Lite)Address Family Transition Router (AFTR) and Basic Bridging BroadBand(B4) elements. |
|
| |
| RFC 8514 | Internet Message Access Protocol (IMAP) - SAVEDATE Extension |
| |
| Authors: | S. Bosch. |
| Date: | January 2019 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8514 |
|
This document adds a new capability called "SAVEDATE" to the InternetMessage Access Protocol (IMAP). It defines a new IMAP message attribute called "save date" that, unlike the existing "internal date" attribute, always indicates the moment at which the message was saved in its current mailbox. The SAVEDATE capability extends theFETCH command with the means to retrieve the save date attribute and extends the SEARCH command to allow using the save date attribute in searching criteria. |
|
| |
| RFC 8515 | URN Namespace for ETSI Documents |
| |
| Authors: | M. Jethanandani, M.A. Reina Ortega. |
| Date: | February 2019 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8515 |
|
This document describes the Namespace Identifier (NID) "etsi" forUniform Resource Names (URNs) used to identify resources published by the European Telecommunications Standards Institute(http://etsi.org). ETSI specifies and manages resources that utilize this URN identification model. Management activities for these and other resource types are handled by the manager of the ETSI ProtocolNaming and Numbering Service (PNNS). |
|
| |
| RFC 8516 | "Too Many Requests" Response Code for the Constrained Application Protocol |
| |
| Authors: | A. Keranen. |
| Date: | January 2019 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8516 |
|
A Constrained Application Protocol (CoAP) server can experience temporary overload because one or more clients are sending requests to the server at a higher rate than the server is capable or willing to handle. This document defines a new CoAP response code for a server to indicate that a client should reduce the rate of requests. |
|
| |
| RFC 8517 | An Inventory of Transport-Centric Functions Provided by Middleboxes: An Operator Perspective |
| |
| Authors: | D. Dolson, Ed., J. Snellman, M. Boucadair, Ed., C. Jacquenet. |
| Date: | February 2019 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8517 |
|
This document summarizes an operator's perception of the benefits that may be provided by intermediary devices that execute functions beyond normal IP forwarding. Such intermediary devices are often called "middleboxes".
RFC 3234 defines a taxonomy of middleboxes and issues in theInternet. Most of those middleboxes utilize or modify application- layer data. This document primarily focuses on devices that observe and act on information carried in the transport layer, and especially information carried in TCP packets. |
|
| |
| RFC 8518 | Selection of Loop-Free Alternates for Multi-Homed Prefixes |
| |
| Authors: | P. Sarkar, Ed., U. Chunduri, Ed., S. Hegde, J. Tantsura, H. Gredler. |
| Date: | March 2019 |
| Formats: | txt json html |
| Updates: | RFC 5286 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8518 |
|
Deployment experience gained from implementing algorithms to determine Loop-Free Alternates (LFAs) for multi-homed prefixes (MHPs) has revealed some avenues for potential improvement. This document provides explicit inequalities that can be used to evaluate neighbors as potential alternates for MHPs. It also provides detailed criteria for evaluating potential alternates for external prefixes advertised by OSPF ASBRs. This document updates Section 6 of RFC 5286 by expanding some of the routing aspects. |
|
| |
| RFC 8519 | YANG Data Model for Network Access Control Lists (ACLs) |
| |
| Authors: | M. Jethanandani, S. Agarwal, L. Huang, D. Blair. |
| Date: | March 2019 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8519 |
|
This document defines a data model for Access Control Lists (ACLs).An ACL is a user-ordered set of rules used to configure the forwarding behavior in a device. Each rule is used to find a match on a packet and define actions that will be performed on the packet. |
|
| |
| RFC 8520 | Manufacturer Usage Description Specification |
| |
| Authors: | E. Lear, R. Droms, D. Romascanu. |
| Date: | March 2019 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8520 |
|
This memo specifies a component-based architecture for ManufacturerUsage Descriptions (MUDs). The goal of MUD is to provide a means for end devices to signal to the network what sort of access and network functionality they require to properly function. The initial focus is on access control. Later work can delve into other aspects.
This memo specifies two YANG modules, IPv4 and IPv6 DHCP options, aLink Layer Discovery Protocol (LLDP) TLV, a URL, an X.509 certificate extension, and a means to sign and verify the descriptions. |
|
| |
| RFC 8521 | Registration Data Access Protocol (RDAP) Object Tagging |
| |
|
|
The Registration Data Access Protocol (RDAP) includes a method that can be used to identify the authoritative server for processing domain name, IP address, and autonomous system number queries. The method does not describe how to identify the authoritative server for processing other RDAP query types, such as entity queries. This limitation exists because the identifiers associated with these query types are typically unstructured. This document updates RFC 7484 by describing an operational practice that can be used to add structure to RDAP identifiers and that makes it possible to identify the authoritative server for additional RDAP queries. |
|
| |
| RFC 8522 | Looking Glass Command Set |
| |
| Authors: | M. Stubbig. |
| Date: | February 2019 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8522 |
|
This document introduces a command set standard to the web-based"Network Looking Glass" software. Its purpose is to provide application programmers uniform access to the Looking Glass service and to analyze a standardized response.
The interface is supposed to provide the same level of information as web-based interfaces, but in a computer-readable format. |
|
| |
| RFC 8525 | YANG Library |
| |
| Authors: | A. Bierman, M. Bjorklund, J. Schoenwaelder, K. Watsen, R. Wilton. |
| Date: | March 2019 |
| Formats: | txt json html |
| Obsoletes: | RFC 7895 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8525 |
|
This document describes a YANG library that provides information about the YANG modules, datastores, and datastore schemas used by a network management server. Simple caching mechanisms are provided to allow clients to minimize retrieval of this information. This version of the YANG library supports the Network Management DatastoreArchitecture (NMDA) by listing all datastores supported by a network management server and the schema that is used by each of these datastores.
This document obsoletes RFC 7895. |
|
| |
| RFC 8526 | NETCONF Extensions to Support the Network Management Datastore Architecture |
| |
| Authors: | M. Bjorklund, J. Schoenwaelder, P. Shafer, K. Watsen, R. Wilton. |
| Date: | March 2019 |
| Formats: | txt html json |
| Updates: | RFC 6241, RFC 7950 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8526 |
|
This document extends the Network Configuration Protocol (NETCONF) defined in RFC 6241 in order to support the Network ManagementDatastore Architecture (NMDA) defined in RFC 8342.
This document updates RFCs 6241 and 7950. The update to RFC 6241 adds new <get-data&rt; and <edit-data&rt; operations and augments existing<lock&rt;, <unlock&rt;, and <validate&rt; operations. The update to RFC 7950 requires the usage of the YANG library (described in RFC 8525) byNETCONF servers implementing the NMDA. |
|
| |
| RFC 8527 | RESTCONF Extensions to Support the Network Management Datastore Architecture |
| |
| Authors: | M. Bjorklund, J. Schoenwaelder, P. Shafer, K. Watsen, R. Wilton. |
| Date: | March 2019 |
| Formats: | txt html json |
| Updates: | RFC 8040 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8527 |
|
This document extends the RESTCONF protocol defined in RFC 8040 in order to support the Network Management Datastore Architecture (NMDA) defined in RFC 8342.
This document updates RFC 8040 by introducing new datastore resources, adding a new query parameter, and requiring the usage of the YANG library (described in RFC 8525) by RESTCONF servers implementing the NMDA. |
|
| |
| RFC 8528 | YANG Schema Mount |
| |
| Authors: | M. Bjorklund, L. Lhotka. |
| Date: | March 2019 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8528 |
|
This document defines a mechanism that adds the schema trees defined by a set of YANG modules onto a mount point defined in the schema tree in another YANG module. |
|
| |
| RFC 8529 | YANG Data Model for Network Instances |
| |
| Authors: | L. Berger, C. Hopps, A. Lindem, D. Bogdanovic, X. Liu. |
| Date: | March 2019 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8529 |
|
This document defines a network instance module. This module can be used to manage the virtual resource partitioning that may be present on a network device. Examples of common industry terms for virtual resource partitioning are VPN Routing and Forwarding (VRF) instances and Virtual Switch Instances (VSIs).
The YANG data model in this document conforms to the NetworkManagement Datastore Architecture (NMDA) defined in RFC 8342. |
|
| |
| RFC 8530 | YANG Model for Logical Network Elements |
| |
| Authors: | L. Berger, C. Hopps, A. Lindem, D. Bogdanovic, X. Liu. |
| Date: | March 2019 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8530 |
|
This document defines a logical network element (LNE) YANG module that is compliant with the Network Management Datastore Architecture(NMDA). This module can be used to manage the logical resource partitioning that may be present on a network device. Examples of common industry terms for logical resource partitioning are logical systems or logical routers. The YANG model in this document conforms with NMDA as defined in RFC 8342. |
|
| |
| RFC 8531 | Generic YANG Data Model for Connection-Oriented Operations, Administration, and Maintenance (OAM) Protocols |
| |
| Authors: | D. Kumar, Q. Wu, Z. Wang. |
| Date: | April 2019 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8531 |
|
This document presents a base YANG data model for connection-orientedOperations, Administration, and Maintenance (OAM) protocols. It provides a technology-independent abstraction of key OAM constructs for such protocols. The model presented here can be extended to include technology-specific details. This guarantees uniformity in the management of OAM protocols and provides support for nested OAM workflows (i.e., performing OAM functions at different levels through a unified interface).
The YANG data model in this document conforms to the NetworkManagement Datastore Architecture. |
|
| |
| RFC 8532 | Generic YANG Data Model for the Management of Operations, Administration, and Maintenance (OAM) Protocols That Use Connectionless Communications |
| |
| Authors: | D. Kumar, Z. Wang, Q. Wu, Ed., R. Rahman, S. Raghavan. |
| Date: | April 2019 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8532 |
|
This document presents a base YANG Data model for the management ofOperations, Administration, and Maintenance (OAM) protocols that use connectionless communications. The data model is defined using theYANG data modeling language, as specified in RFC 7950. It provides a technology-independent abstraction of key OAM constructs for OAM protocols that use connectionless communication. The base model presented here can be extended to include technology-specific details.
There are two key benefits of this approach: First, it leads to uniformity between OAM protocols. Second, it supports both nestedOAM workflows (i.e., performing OAM functions at the same level or different levels through a unified interface) as well as interactiveOAM workflows (i.e., performing OAM functions at the same level through a unified interface). |
|
| |
| RFC 8533 | A YANG Data Model for Retrieval Methods for the Management of Operations, Administration, and Maintenance (OAM) Protocols That Use Connectionless Communications |
| |
| Authors: | D. Kumar, M. Wang, Q. Wu, Ed., R. Rahman, S. Raghavan. |
| Date: | April 2019 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8533 |
|
This document presents a retrieval method YANG data model for connectionless Operations, Administration, and Maintenance (OAM) protocols. It provides technology-independent RPC operations for OAM protocols that use connectionless communication. The retrieval methods model herein presented can be extended to include technology- specific details. There are two key benefits of this approach:First, it leads to uniformity between OAM protocols. Second, it supports both nested OAM workflows (i.e., performing OAM functions at different or the same levels through a unified interface) as well as interactive OAM workflows (i.e., performing OAM functions at the same levels through a unified interface). |
|
| |
| RFC 8534 | Explicit Tracking with Wildcard Routes in Multicast VPN |
| |
|
|
The base Multicast VPN (MVPN) specifications (RFCs 6513 and 6514) provide procedures to allow a multicast ingress node to invoke"explicit tracking" for a multicast flow or set of flows, thus learning the egress nodes for that flow or set of flows. However, the specifications are not completely clear about how the explicit tracking procedures work in certain scenarios. This document provides the necessary clarifications. It also specifies a new, optimized explicit-tracking procedure. This new procedure allows an ingress node, by sending a single message, to request explicit tracking of each of a set of flows, where the set of flows is specified using a wildcard mechanism. This document updates RFCs6514, 6625, 7524, 7582, and 7900. |
|
| |
| RFC 8536 | The Time Zone Information Format (TZif) |
| |
| Authors: | A. Olson, P. Eggert, K. Murchison. |
| Date: | February 2019 |
| Formats: | txt html json |
| Obsoleted by: | RFC 9636 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8536 |
|
This document specifies the Time Zone Information Format (TZif) for representing and exchanging time zone information, independent of any particular service or protocol. Two media types for this format are also defined. |
|
| |
| RFC 8537 | Updates to the Fast Reroute Procedures for Co-routed Associated Bidirectional Label Switched Paths (LSPs) |
| |
|
|
Resource Reservation Protocol (RSVP) association signaling can be used to bind two unidirectional Label Switched Paths (LSPs) into an associated bidirectional LSP. When an associated bidirectional LSP is co-routed, the reverse LSP follows the same path as its forwardLSP. This document updates the fast reroute procedures defined inRFC 4090 to support both single-sided and double-sided provisioned associated bidirectional LSPs. This document also updates the procedure for associating two reverse LSPs defined in RFC 7551 to support co-routed bidirectional LSPs. The fast reroute procedures can ensure that, for the co-routed LSPs, traffic flows on co-routed paths in the forward and reverse directions after a failure event. |
|
| |
| RFC 8538 | Notification Message Support for BGP Graceful Restart |
| |
| Authors: | K. Patel, R. Fernando, J. Scudder, J. Haas. |
| Date: | March 2019 |
| Formats: | txt json html |
| Updates: | RFC 4724 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8538 |
|
The BGP Graceful Restart mechanism defined in RFC 4724 limits the usage of BGP Graceful Restart to BGP messages other than BGPNOTIFICATION messages. This document updates RFC 4724 by defining an extension that permits the Graceful Restart procedures to be performed when the BGP speaker receives a BGP NOTIFICATION message or the Hold Time expires. This document also defines a new subcode forBGP Cease NOTIFICATION messages; this new subcode requests a full session restart instead of a Graceful Restart. |
|
| |
| RFC 8539 | Softwire Provisioning Using DHCPv4 over DHCPv6 |
| |
| Authors: | I. Farrer, Q. Sun, Y. Cui, L. Sun. |
| Date: | March 2019 |
| Formats: | txt json html |
| Updates: | RFC 7598 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8539 |
|
DHCPv4 over DHCPv6 (RFC 7341) is a mechanism for dynamically configuring IPv4 for use as an over-the-top service in an IPv6-only network. Softwires are an example of such a service. For DHCPv4 over DHCPv6 (DHCP 4o6) to function with some IPv4-over-IPv6 softwire mechanisms and deployment scenarios (e.g., RFC 7596 or RFC 7597), the operator needs to know the IPv6 address that the client will use as the source of an IPv4-in-IPv6 softwire tunnel. This address, in conjunction with the client's IPv4 address, and (in some deployments) the Port Set ID are used to create a binding table entry in the operator's softwire tunnel concentrator. This memo defines a DHCPv6 option to convey IPv6 parameters for establishing the softwire tunnel and a DHCPv4 option (to be used only with DHCP 4o6) to communicate the source tunnel IPv6 address between the DHCP 4o6 client and server. It is designed to work in conjunction with the IPv4 address allocation process.
"DHCPv6 Options for Configuration of Softwire Address and Port-MappedClients" (RFC 7598) describes a deterministic DHCPv6-based mechanism for provisioning softwires. This document updates RFC 7598, allowingOPTION_S46_BR (90) to be enumerated in the DHCPv6 client's OptionRequest Option (ORO) request and to appear directly within subsequent messages sent by the DHCPv6 server. |
|
| |
| RFC 8540 | Stream Control Transmission Protocol: Errata and Issues in RFC 4960 |
| |
| Authors: | R. Stewart, M. Tuexen, M. Proshin. |
| Date: | February 2019 |
| Formats: | txt html json |
| Obsoleted by: | RFC 9260 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8540 |
|
This document is a compilation of issues found since the publication of RFC 4960 in September 2007, based on experience with implementing, testing, and using the Stream Control Transmission Protocol (SCTP) along with the suggested fixes. This document provides deltas to RFC4960 and is organized in a time-ordered way. The issues are listed in the order in which they were brought up. Because some text is changed several times, the last delta in the text is the one that should be applied. In addition to the deltas, a description of each problem and the details of the solution for each are also provided. |
|
| |
| RFC 8541 | Impact of Shortest Path First (SPF) Trigger and Delay Strategies on IGP Micro-loops |
| |
| Authors: | S. Litkowski, B. Decraene, M. Horneffer. |
| Date: | March 2019 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8541 |
|
A micro-loop is a packet-forwarding loop that may occur transiently among two or more routers in a hop-by-hop packet-forwarding paradigm.
This document analyzes the impact of using different link state IGP implementations in a single network with respect to micro-loops. The analysis is focused on the Shortest Path First (SPF) delay algorithm but also mentions the impact of SPF trigger strategies. |
|
| |
| RFC 8542 | A YANG Data Model for Fabric Topology in Data-Center Networks |
| |
| Authors: | Y. Zhuang, D. Shi, R. Gu, H. Ananthakrishnan. |
| Date: | March 2019 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8542 |
|
This document defines a YANG data model for fabric topology in data- center networks and represents one possible view of the data-center fabric. This document focuses on the data model only and does not endorse any kind of network design that could be based on the abovementioned model. |
|
| |
| RFC 8543 | Extensible Provisioning Protocol (EPP) Organization Mapping |
| |
| Authors: | L. Zhou, N. Kong, J. Yao, J. Gould, G. Zhou. |
| Date: | March 2019 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8543 |
|
This document describes an Extensible Provisioning Protocol (EPP) mapping for provisioning and management of organization objects stored in a shared central repository. |
|
| |
| RFC 8544 | Organization Extension for the Extensible Provisioning Protocol (EPP) |
| |
| Authors: | L. Zhou, N. Kong, J. Wei, J. Yao, J. Gould. |
| Date: | April 2019 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8544 |
|
This document describes an extension to Extensible ProvisioningProtocol (EPP) object mappings that is designed to support assigning an organization to any existing object (domain, host, contact) as well as any future objects. |
|
| |
| RFC 8545 | Well-Known Port Assignments for the One-Way Active Measurement Protocol (OWAMP) and the Two-Way Active Measurement Protocol (TWAMP) |
| |
|
|
This memo explains the motivation and describes the reassignment of well-known ports for the One-Way Active Measurement Protocol (OWAMP) and the Two-Way Active Measurement Protocol (TWAMP) for control and measurement. It also clarifies the meaning and composition of theseStandards Track protocol names for the industry.
This memo updates RFCs 4656 and 5357, in terms of the UDP well-known port assignments, and it clarifies the complete OWAMP and TWAMP protocol composition for the industry. |
|
| |
| RFC 8546 | The Wire Image of a Network Protocol |
| |
| Authors: | B. Trammell, M. Kuehlewind. |
| Date: | April 2019 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8546 |
|
This document defines the wire image, an abstraction of the information available to an on-path non-participant in a networking protocol. This abstraction is intended to shed light on the implications that increased encryption has for network functions that use the wire image. |
|
| |
| RFC 8547 | TCP-ENO: Encryption Negotiation Option |
| |
| Authors: | A. Bittau, D. Giffin, M. Handley, D. Mazieres, E. Smith. |
| Date: | May 2019 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 8547 |
|
Despite growing adoption of TLS, a significant fraction of TCP traffic on the Internet remains unencrypted. The persistence of unencrypted traffic can be attributed to at least two factors.First, some legacy protocols lack a signaling mechanism (such as aSTARTTLS command) by which to convey support for encryption, thus making incremental deployment impossible. Second, legacy applications themselves cannot always be upgraded and therefore require a way to implement encryption transparently entirely within the transport layer. The TCP Encryption Negotiation Option (TCP-ENO) addresses both of these problems through a new TCP option kind providing out-of-band, fully backward-compatible negotiation of encryption. |
|
| |
| RFC 8548 | Cryptographic Protection of TCP Streams (tcpcrypt) |
| |
| Authors: | A. Bittau, D. Giffin, M. Handley, D. Mazieres, Q. Slack, E. Smith. |
| Date: | May 2019 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 8548 |
|
This document specifies "tcpcrypt", a TCP encryption protocol designed for use in conjunction with the TCP Encryption NegotiationOption (TCP-ENO). Tcpcrypt coexists with middleboxes by tolerating resegmentation, NATs, and other manipulations of the TCP header. The protocol is self-contained and specifically tailored to TCP implementations, which often reside in kernels or other environments in which large external software dependencies can be undesirable.Because the size of TCP options is limited, the protocol requires one additional one-way message latency to perform key exchange before application data can be transmitted. However, the extra latency can be avoided between two hosts that have recently established a previous tcpcrypt connection. |
|
| |
| RFC 8549 | Export of BGP Community Information in IP Flow Information Export (IPFIX) |
| |
| Authors: | Z. Li, R. Gu, J. Dong. |
| Date: | April 2019 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8549 |
|
By introducing new Information Elements (IEs), this document extends the existing BGP-related IEs to enable IP Flow Information Export(IPFIX) to export BGP community information, including the BGPStandard Communities defined in RFC 1997, BGP Extended Communities defined in RFC 4360, and BGP Large Communities defined in RFC 8092.According to the network operator's BGP community planning, network traffic information can then be accumulated and analyzed at the BGP community granularity, which represents the traffic of different kinds of customers, services, or geographical regions. Network traffic information at the BGP community granularity is useful for network traffic analysis and engineering. |
|
| |
| RFC 8550 | Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Certificate Handling |
| |
| Authors: | J. Schaad, B. Ramsdell, S. Turner. |
| Date: | April 2019 |
| Formats: | txt html json |
| Obsoletes: | RFC 5750 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8550 |
|
This document specifies conventions for X.509 certificate usage bySecure/Multipurpose Internet Mail Extensions (S/MIME) v4.0 agents.S/MIME provides a method to send and receive secure MIME messages, and certificates are an integral part of S/MIME agent processing.S/MIME agents validate certificates as described in RFC 5280("Internet X.509 Public Key Infrastructure Certificate andCertificate Revocation List (CRL) Profile"). S/MIME agents must meet the certificate-processing requirements in this document as well as those in RFC 5280. This document obsoletes RFC 5750. |
|
| |
| RFC 8551 | Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Message Specification |
| |
| Authors: | J. Schaad, B. Ramsdell, S. Turner. |
| Date: | April 2019 |
| Formats: | txt html json |
| Obsoletes: | RFC 5751 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8551 |
|
This document defines Secure/Multipurpose Internet Mail Extensions(S/MIME) version 4.0. S/MIME provides a consistent way to send and receive secure MIME data. Digital signatures provide authentication, message integrity, and non-repudiation with proof of origin.Encryption provides data confidentiality. Compression can be used to reduce data size. This document obsoletes RFC 5751. |
|
| |
| RFC 8552 | Scoped Interpretation of DNS Resource Records through "Underscored" Naming of Attribute Leaves |
| |
|
|
Formally, any DNS Resource Record (RR) may occur under any domain name. However, some services use an operational convention for defining specific interpretations of an RRset by locating the records in a DNS branch under the parent domain to which the RRset actually applies. The top of this subordinate branch is defined by a naming convention that uses a reserved node name, which begins with the underscore character (e.g., "_name"). The underscored naming construct defines a semantic scope for DNS record types that are associated with the parent domain above the underscored branch. This specification explores the nature of this DNS usage and defines the"Underscored and Globally Scoped DNS Node Names" registry with IANA.The purpose of this registry is to avoid collisions resulting from the use of the same underscored name for different services. |
|
| |
| RFC 8553 | DNS Attrleaf Changes: Fixing Specifications That Use Underscored Node Names |
| |
| Authors: | D. Crocker. |
| Date: | March 2019 |
| Formats: | txt json html |
| Updates: | RFC 2782, RFC 3263, RFC 3529, RFC 3620, RFC 3832, RFC 3887, RFC 3958, RFC 4120, RFC 4227, RFC 4386, RFC 4387, RFC 4976, RFC 5026, RFC 5328, RFC 5389, RFC 5415, RFC 5518, RFC 5555, RFC 5617, RFC 5679, RFC 5766, RFC 5780, RFC 5804, RFC 5864, RFC 5928, RFC 6120, RFC 6186, RFC 6376, RFC 6733, RFC 6763, RFC 7208, RFC 7489, RFC 8145 |
| Also: | BCP 0222 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 8553 |
|
Using an underscore for a prefix creates a space for constrained interoperation of resource records. Original uses of an underscore character as a domain node name prefix were specified without the benefit of an IANA registry. This produced an entirely uncoordinated set of name-creation activities, all drawing from the same namespace.A registry for these names has now been defined by RFC 8552.However, the existing specifications that use underscored naming need to be modified in order to be in line with the new registry. This document specifies those changes. The changes preserve existing software and operational practice, while adapting the specifications for those practices to the newer underscore registry model. |
|
| |
| RFC 8554 | Leighton-Micali Hash-Based Signatures |
| |
| Authors: | D. McGrew, M. Curcio, S. Fluhrer. |
| Date: | April 2019 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8554 |
|
This note describes a digital-signature system based on cryptographic hash functions, following the seminal work in this area of Lamport,Diffie, Winternitz, and Merkle, as adapted by Leighton and Micali in1995. It specifies a one-time signature scheme and a general signature scheme. These systems provide asymmetric authentication without using large integer mathematics and can achieve a high security level. They are suitable for compact implementations, are relatively simple to implement, and are naturally resistant to side- channel attacks. Unlike many other signature systems, hash-based signatures would still be secure even if it proves feasible for an attacker to build a quantum computer.
This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF. This has been reviewed by many researchers, both in the research group and outside of it. The Acknowledgements section lists many of them. |
|
| |
| RFC 8555 | Automatic Certificate Management Environment (ACME) |
| |
| Authors: | R. Barnes, J. Hoffman-Andrews, D. McCarney, J. Kasten. |
| Date: | March 2019 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8555 |
|
Public Key Infrastructure using X.509 (PKIX) certificates are used for a number of purposes, the most significant of which is the authentication of domain names. Thus, certification authorities(CAs) in the Web PKI are trusted to verify that an applicant for a certificate legitimately represents the domain name(s) in the certificate. As of this writing, this verification is done through a collection of ad hoc mechanisms. This document describes a protocol that a CA and an applicant can use to automate the process of verification and certificate issuance. The protocol also provides facilities for other certificate management functions, such as certificate revocation. |
|
| |
| RFC 8556 | Multicast VPN Using Bit Index Explicit Replication (BIER) |
| |
| Authors: | E. Rosen, Ed., M. Sivakumar, T. Przygienda, S. Aldrin, A. Dolganow. |
| Date: | April 2019 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8556 |
|
The Multicast Virtual Private Network (MVPN) specifications require the use of multicast tunnels ("P-tunnels") that traverse a service provider's backbone network. The P-tunnels are used for carrying multicast traffic across the backbone. A variety of P-tunnel types are supported. Bit Index Explicit Replication (BIER) is a new architecture that provides optimal multicast forwarding through a"multicast domain", without requiring intermediate routers to maintain any per-flow state or to engage in an explicit tree-building protocol. This document specifies the protocol and procedures that allow MVPN to use BIER as the method of carrying multicast traffic over a service provider's backbone network. |
|
| |
| RFC 8557 | Deterministic Networking Problem Statement |
| |
| Authors: | N. Finn, P. Thubert. |
| Date: | May 2019 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8557 |
|
This paper documents the needs in various industries to establish multi-hop paths for characterized flows with deterministic properties. |
|
| |
| RFC 8558 | Transport Protocol Path Signals |
| |
| Authors: | T. Hardie, Ed.. |
| Date: | April 2019 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8558 |
|
This document discusses the nature of signals seen by on-path elements examining transport protocols, contrasting implicit and explicit signals. For example, TCP's state machine uses a series of well-known messages that are exchanged in the clear. Because these are visible to network elements on the path between the two nodes setting up the transport connection, they are often used as signals by those network elements. In transports that do not exchange these messages in the clear, on-path network elements lack those signals.Often, the removal of those signals is intended by those moving the messages to confidential channels. Where the endpoints desire that network elements along the path receive these signals, this document recommends explicit signals be used. |
|
| |
| RFC 8559 | Dynamic Authorization Proxying in the Remote Authentication Dial-In User Service (RADIUS) Protocol |
| |
|
|
RFC 5176 defines Change-of-Authorization (CoA) and Disconnect Message(DM) behavior for RADIUS. RFC 5176 also suggests that proxying these messages is possible, but it does not provide guidance as to how that is done. This specification updates RFC 5176 to correct that omission for scenarios where networks use realm-based proxying as defined in RFC 7542. This specification also updates RFC 5580 to allow the Operator-Name attribute in CoA-Request and Disconnect-Request packets. |
|
| |
| RFC 8560 | Seamless Integration of Ethernet VPN (EVPN) with Virtual Private LAN Service (VPLS) and Their Provider Backbone Bridge (PBB) Equivalents |
| |
| Authors: | A. Sajassi, Ed., S. Salam, N. Del Regno, J. Rabadan. |
| Date: | May 2019 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8560 |
|
This document specifies mechanisms for backward compatibility ofEthernet VPN (EVPN) and Provider Backbone Bridge Ethernet VPN(PBB-EVPN) solutions with Virtual Private LAN Service (VPLS) andProvider Backbone Bridge VPLS (PBB-VPLS) solutions. It also provides mechanisms for the seamless integration of these two technologies in the same MPLS/IP network on a per-VPN-instance basis. Implementation of this document enables service providers to introduce EVPN/PBB-EVPNProvider Edges (PEs) in their brownfield deployments of VPLS/PBB-VPLS networks. This document specifies the control-plane and forwarding behavior needed for the auto-discovery of the following: 1) a VPN instance, 2) multicast and unicast operation, and 3) a Media AccessControl (MAC) mobility operation. This enables seamless integration between EVPN and VPLS PEs as well as between PBB-VPLS and PBB-EVPNPEs. |
|
| |
| RFC 8561 | A YANG Data Model for Microwave Radio Link |
| |
| Authors: | J. Ahlberg, M. Ye, X. Li, D. Spreafico, M. Vaupotic. |
| Date: | June 2019 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8561 |
|
This document defines a YANG data model for control and management of radio link interfaces and their connectivity to packet (typicallyEthernet) interfaces in a microwave/millimeter wave node. The data nodes for management of the interface protection functionality is broken out into a separate and generic YANG data model in order to make it available for other interface types as well. |
|
| |
| RFC 8562 | Bidirectional Forwarding Detection (BFD) for Multipoint Networks |
| |
| Authors: | D. Katz, D. Ward, S. Pallagatti, Ed., G. Mirsky, Ed.. |
| Date: | April 2019 |
| Formats: | txt json html |
| Updates: | RFC 5880 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8562 |
|
This document describes extensions to the Bidirectional ForwardingDetection (BFD) protocol for its use in multipoint and multicast networks.
This document updates RFC 5880. |
|
| |
| RFC 8563 | Bidirectional Forwarding Detection (BFD) Multipoint Active Tails |
| |
| Authors: | D. Katz, D. Ward, S. Pallagatti, Ed., G. Mirsky, Ed.. |
| Date: | April 2019 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8563 |
|
This document describes active tail extensions to the BidirectionalForwarding Detection (BFD) protocol for multipoint networks. |
|
| |
| RFC 8564 | Support of Point-to-Multipoint Bidirectional Forwarding Detection (BFD) in Transparent Interconnection of Lots of Links (TRILL) |
| |
|
|
Point-to-multipoint (P2MP) Bidirectional Forwarding Detection (BFD) is designed to verify multipoint connectivity. This document specifies the support of P2MP BFD in Transparent Interconnection ofLots of Links (TRILL). Similar to TRILL point-to-point BFD, BFDControl packets in TRILL P2MP BFD are transmitted using RBridgeChannel messages. This document updates RFCs 7175 and 7177. |
|
| |
| RFC 8565 | Hypertext Jeopardy Protocol (HTJP/1.0) |
| |
| Authors: | E. Fokschaner. |
| Date: | 1 April 2019 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8565 |
|
The Hypertext Jeopardy Protocol (HTJP) inverts the request/response semantics of the Hypertext Transfer Protocol (HTTP). Using conventional HTTP, one connects to a server, asks a question, and expects a correct answer. Using HTJP, one connects to a server, sends an answer, and expects a correct question. This document specifies the semantics of HTJP. |
|
| |
| RFC 8567 | Customer Management DNS Resource Records |
| |
| Authors: | E. Rye, R. Beverly. |
| Date: | 1 April 2019 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8567 |
|
Maintaining high Quality of Experience (QoE) increasingly requires end-to-end, holistic network management, including managed CustomerPremises Equipment (CPE). Because customer management is a shared global responsibility, the Domain Name System (DNS) provides an ideal existing infrastructure for maintaining authoritative customer information that must be readily, reliably, and publicly accessible.
This document describes four new DNS resource record types for encoding customer information in the DNS. These records are intended to better facilitate high customer QoE via inter-provider cooperation and management of customer data. |
|
| |
| RFC 8568 | Network Virtualization Research Challenges |
| |
| Authors: | CJ. Bernardos, A. Rahman, JC. Zuniga, LM. Contreras, P. Aranda, P. Lynch. |
| Date: | April 2019 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8568 |
|
This document describes open research challenges for network virtualization. Network virtualization is following a similar path as previously taken by cloud computing. Specifically, cloud computing popularized migration of computing functions (e.g., applications) and storage from local, dedicated, physical resources to remote virtual functions accessible through the Internet. In a similar manner, network virtualization is encouraging migration of networking functions from dedicated physical hardware nodes to a virtualized pool of resources. However, network virtualization can be considered to be a more complex problem than cloud computing as it not only involves virtualization of computing and storage functions but also involves abstraction of the network itself. This document describes current research and engineering challenges in network virtualization including the guarantee of quality of service, performance improvement, support for multiple domains, network slicing, service composition, device virtualization, privacy and security, separation of control concerns, network function placement, and testing. In addition, some proposals are made for new activities in the IETF and IRTF that could address some of these challenges.This document is a product of the Network Function VirtualizationResearch Group (NFVRG). |
|
| |
| RFC 8569 | Content-Centric Networking (CCNx) Semantics |
| |
| Authors: | M. Mosko, I. Solis, C. Wood. |
| Date: | July 2019 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 8569 |
|
This document describes the core concepts of the Content-CentricNetworking (CCNx) architecture and presents a network protocol based on two messages: Interests and Content Objects. It specifies the set of mandatory and optional fields within those messages and describes their behavior and interpretation. This architecture and protocol specification is independent of a specific wire encoding.
The protocol also uses a control message called an Interest Return, whereby one system can return an Interest message to the previous hop due to an error condition. This indicates to the previous hop that the current system will not respond to the Interest.
This document is a product of the Information-Centric NetworkingResearch Group (ICNRG). The document received wide review amongICNRG participants. Two full implementations are in active use and have informed the technical maturity of the protocol specification. |
|
| |
| RFC 8570 | IS-IS Traffic Engineering (TE) Metric Extensions |
| |
| Authors: | L. Ginsberg, Ed., S. Previdi, Ed., S. Giacalone, D. Ward, J. Drake, Q. Wu. |
| Date: | March 2019 |
| Formats: | txt html json |
| Obsoletes: | RFC 7810 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8570 |
|
In certain networks, such as, but not limited to, financial information networks (e.g., stock market data providers), network- performance criteria (e.g., latency) are becoming as critical to data-path selection as other metrics.
This document describes extensions to IS-IS Traffic EngineeringExtensions (RFC 5305). These extensions provide a way to distribute and collect network-performance information in a scalable fashion.The information distributed using IS-IS TE Metric Extensions can then be used to make path-selection decisions based on network performance.
Note that this document only covers the mechanisms with which network-performance information is distributed. The mechanisms for measuring network performance or acting on that information, once distributed, are outside the scope of this document.
This document obsoletes RFC 7810. |
|
| |
| RFC 8571 | BGP - Link State (BGP-LS) Advertisement of IGP Traffic Engineering Performance Metric Extensions |
| |
| Authors: | L. Ginsberg, Ed., S. Previdi, Q. Wu, J. Tantsura, C. Filsfils. |
| Date: | March 2019 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8571 |
|
This document defines new BGP - Link State (BGP-LS) TLVs in order to carry the IGP Traffic Engineering Metric Extensions defined in theIS-IS and OSPF protocols. |
|
| |
| RFC 8572 | Secure Zero Touch Provisioning (SZTP) |
| |
| Authors: | K. Watsen, I. Farrer, M. Abrahamsson. |
| Date: | April 2019 |
| Formats: | txt json html |
| Updated by: | RFC 9646 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8572 |
|
This document presents a technique to securely provision a networking device when it is booting in a factory-default state. Variations in the solution enable it to be used on both public and private networks. The provisioning steps are able to update the boot image, commit an initial configuration, and execute arbitrary scripts to address auxiliary needs. The updated device is subsequently able to establish secure connections with other systems. For instance, a device may establish NETCONF (RFC 6241) and/or RESTCONF (RFC 8040) connections with deployment-specific network management systems. |
|
| |
| RFC 8573 | Message Authentication Code for the Network Time Protocol |
| |
|
|
The Network Time Protocol (NTP), as described in RFC 5905, states that NTP packets should be authenticated by appending NTP data to a128-bit key and hashing the result with MD5 to obtain a 128-bit tag.This document deprecates MD5-based authentication, which is considered too weak, and recommends the use of AES-CMAC as described in RFC 4493 as a replacement. |
|
| |
| RFC 8574 | cite-as: A Link Relation to Convey a Preferred URI for Referencing |
| |
| Authors: | H. Van de Sompel, M. Nelson, G. Bilder, J. Kunze, S. Warner. |
| Date: | April 2019 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8574 |
|
A web resource is routinely referenced by means of the URI with which it is directly accessed. But cases exist where referencing a resource by means of a different URI is preferred. This specification defines a link relation type that can be used to convey such a preference. |
|
| |
| RFC 8575 | YANG Data Model for the Precision Time Protocol (PTP) |
| |
| Authors: | Y. Jiang, Ed., X. Liu, J. Xu, R. Cummings, Ed.. |
| Date: | May 2019 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8575 |
|
This document defines a YANG data model for the configuration of devices and clocks using the Precision Time Protocol (PTP) as specified in IEEE Std 1588-2008. It also defines the retrieval of the configuration information, the data sets and the running states of PTP clocks. The YANG module in this document conforms to theNetwork Management Datastore Architecture (NMDA). |
|
| |
| RFC 8576 | Internet of Things (IoT) Security: State of the Art and Challenges |
| |
| Authors: | O. Garcia-Morchon, S. Kumar, M. Sethi. |
| Date: | April 2019 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8576 |
|
The Internet of Things (IoT) concept refers to the usage of standardInternet protocols to allow for human-to-thing and thing-to-thing communication. The security needs for IoT systems are well recognized, and many standardization steps to provide security have been taken -- for example, the specification of the ConstrainedApplication Protocol (CoAP) secured with Datagram Transport LayerSecurity (DTLS). However, security challenges still exist, not only because there are some use cases that lack a suitable solution, but also because many IoT devices and systems have been designed and deployed with very limited security capabilities. In this document, we first discuss the various stages in the lifecycle of a thing.Next, we document the security threats to a thing and the challenges that one might face to protect against these threats. Lastly, we discuss the next steps needed to facilitate the deployment of secureIoT systems. This document can be used by implementers and authors of IoT specifications as a reference for details about security considerations while documenting their specific security challenges, threat models, and mitigations.
This document is a product of the IRTF Thing-to-Thing Research Group(T2TRG). |
|
| |
| RFC 8577 | Signaling RSVP-TE Tunnels on a Shared MPLS Forwarding Plane |
| |
| Authors: | H. Sitaraman, V. Beeram, T. Parikh, T. Saad. |
| Date: | April 2019 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8577 |
|
As the scale of MPLS RSVP-TE networks has grown, the number of LabelSwitched Paths (LSPs) supported by individual network elements has increased. Various implementation recommendations have been proposed to manage the resulting increase in the amount of control-plane state information.
However, those changes have had no effect on the number of labels that a transit Label Switching Router (LSR) has to support in the forwarding plane. That number is governed by the number of LSPs transiting or terminated at the LSR and is directly related to the total LSP state in the control plane.
This document defines a mechanism to prevent the maximum size of the label space limit on an LSR from being a constraint to control-plane scaling on that node. It introduces the notion of preinstalled'per-TE link labels' that can be shared by MPLS RSVP-TE LSPs that traverse these TE links. This approach significantly reduces the forwarding-plane state required to support a large number of LSPs.This couples the feature benefits of the RSVP-TE control plane with the simplicity of the Segment Routing (SR) MPLS forwarding plane. |
|
| |
| RFC 8578 | Deterministic Networking Use Cases |
| |
| Authors: | E. Grossman, Ed.. |
| Date: | May 2019 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8578 |
|
This document presents use cases for diverse industries that have in common a need for "deterministic flows". "Deterministic" in this context means that such flows provide guaranteed bandwidth, bounded latency, and other properties germane to the transport of time- sensitive data. These use cases differ notably in their network topologies and specific desired behavior, providing as a group broad industry context for Deterministic Networking (DetNet). For each use case, this document will identify the use case, identify representative solutions used today, and describe potential improvements that DetNet can enable. |
|
| |
| RFC 8579 | Sieve Email Filtering: Delivering to Special-Use Mailboxes |
| |
| Authors: | S. Bosch. |
| Date: | May 2019 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8579 |
|
The SPECIAL-USE capability of the IMAP protocol (RFC 6154) allows clients to identify special-use mailboxes, e.g., where draft or sent messages should be put. This simplifies client configuration. In contrast, the Sieve mail filtering language (RFC 5228) currently has no such capability. This memo defines a Sieve extension that fills this gap: it adds a test for checking whether a special-use attribute is assigned for a particular mailbox or any mailbox, and it adds the ability to file messages into a mailbox identified solely by a special-use attribute. |
|
| |
| RFC 8580 | Sieve Extension: File Carbon Copy (FCC) |
| |
|
|
The Sieve email filtering language provides a number of action commands, some of which can generate additional messages on behalf of the user. This document defines an extension to such commands to allow a copy of any generated message to be filed into a target mailbox.
This document updates RFCs 5230 and 5435 by adding a new tagged argument to the Vacation and Notify actions, respectively. |
|
| |
| RFC 8581 | Diameter Agent Overload and the Peer Overload Report |
| |
|
|
This specification documents an extension to the Diameter OverloadIndication Conveyance (DOIC), a base solution for Diameter overload defined in RFC 7683. The extension defines the Peer Overload report type. The initial use case for the peer report is the handling of occurrences of overload of a Diameter Agent. |
|
| |
| RFC 8582 | Diameter Overload Rate Control |
| |
| Authors: | S. Donovan, Ed., E. Noel. |
| Date: | August 2019 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8582 |
|
This specification documents an extension to the Diameter OverloadIndication Conveyance (DOIC) base solution, which is defined in RFC7683. This extension adds a new overload-control abatement algorithm. This abatement algorithm allows for a DOIC reporting node to specify a maximum rate at which a DOIC reacting node sendsDiameter requests to the DOIC reporting node. |
|
| |
| RFC 8583 | Diameter Load Information Conveyance |
| |
| Authors: | B. Campbell, S. Donovan, Ed., JJ. Trottin. |
| Date: | August 2019 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8583 |
|
RFC 7068 describes requirements for Overload Control in Diameter.This includes a requirement to allow Diameter nodes to send "load" information, even when the node is not overloaded. The base solution defined in RFC 7683 (Diameter Overload Information Conveyance (DOIC)) describes a mechanism meeting most of the requirements but does not currently include the ability to send load information. This document defines a mechanism for the conveying of Diameter load information. |
|
| |
| RFC 8584 | Framework for Ethernet VPN Designated Forwarder Election Extensibility |
| |
| Authors: | J. Rabadan, Ed., S. Mohanty, Ed., A. Sajassi, J. Drake, K. Nagaraj, S. Sathappan. |
| Date: | April 2019 |
| Formats: | txt html json |
| Updates: | RFC 7432 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8584 |
|
An alternative to the default Designated Forwarder (DF) selection algorithm in Ethernet VPNs (EVPNs) is defined. The DF is theProvider Edge (PE) router responsible for sending Broadcast, UnknownUnicast, and Multicast (BUM) traffic to a multihomed Customer Edge(CE) device on a given VLAN on a particular Ethernet Segment (ES).In addition, the ability to influence the DF election result for aVLAN based on the state of the associated Attachment Circuit (AC) is specified. This document clarifies the DF election Finite StateMachine in EVPN services. Therefore, it updates the EVPN specification (RFC 7432). |
|
| |
| RFC 8585 | Requirements for IPv6 Customer Edge Routers to Support IPv4-as-a-Service |
| |
| Authors: | J. Palet Martinez, H. M.-H. Liu, M. Kawashima. |
| Date: | May 2019 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8585 |
|
This document specifies the IPv4 service continuity requirements forIPv6 Customer Edge (CE) routers that are provided either by the service provider or by vendors who sell through the retail market.
Specifically, this document extends the basic requirements for IPv6CE routers as described in RFC 7084 to allow the provisioning of IPv6 transition services for the support of IPv4-as-a-Service (IPv4aaS) by means of new transition mechanisms. The document only coversIPv4aaS, i.e., transition technologies for delivering IPv4 inIPv6-only access networks. IPv4aaS is necessary because there aren't sufficient IPv4 addresses available for every possible customer/ device. However, devices or applications in the customer Local AreaNetworks (LANs) may be IPv4-only or IPv6-only and still need to communicate with IPv4-only services on the Internet. |
|
| |
| RFC 8586 | Loop Detection in Content Delivery Networks (CDNs) |
| |
| Authors: | S. Ludin, M. Nottingham, N. Sullivan. |
| Date: | April 2019 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8586 |
|
This document defines the CDN-Loop request header field for HTTP.CDN-Loop addresses an operational need that occurs when an HTTP request is intentionally forwarded between Content Delivery Networks(CDNs), but is then accidentally or maliciously re-routed back into the original CDN causing a non-terminating loop. The new header field can be used to identify the error and terminate the loop. |
|
| |
| RFC 8587 | NFS Version 4.0 Trunking Update |
| |
|
|
In NFS version 4.0, the fs_locations attribute informs clients about alternate locations of file systems. An NFS version 4.0 client can use this information to handle migration and replication of server file systems. This document describes how an NFS version 4.0 client can also use this information to discover an NFS version 4.0 server's trunking capabilities. This document updates RFC 7530. |
|
| |
| RFC 8588 | Personal Assertion Token (PaSSporT) Extension for Signature-based Handling of Asserted information using toKENs (SHAKEN) |
| |
| Authors: | C. Wendt, M. Barnes. |
| Date: | May 2019 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8588 |
|
This document extends the Personal Assertion Token (PASSporT), which is a token object that conveys cryptographically signed information about the participants involved in communications. The extension is defined based on the "Signature-based Handling of Asserted information using toKENs (SHAKEN)" specification by the ATIS/SIPForum IP-NNI Task Group. It provides both (1) a specific set of levels of confidence in the correctness of the originating identity of a call originated in a SIP-based telephone network as well as (2) an identifier that allows the Service Provider (SP) to uniquely identify the origin of the call within its network. |
|
| |
| RFC 8589 | The 'leaptofrogans' URI Scheme |
| |
| Authors: | A. Tamas, B. Phister, Ed., J-E. Rodriguez. |
| Date: | May 2019 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8589 |
|
This document describes the 'leaptofrogans' Uniform ResourceIdentifier (URI) scheme, which enables applications to launch FrogansPlayer on a given Frogans site. Frogans is a medium for publishing content and services on the Internet, defined as a generic software layer on the Internet. Frogans Player is software that enables end users to browse Frogans sites. |
|
| |
| RFC 8590 | Change Poll Extension for the Extensible Provisioning Protocol (EPP) |
| |
| Authors: | J. Gould, K. Feher. |
| Date: | May 2019 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8590 |
|
This document describes an Extensible Provisioning Protocol (EPP) extension for notifying clients of operations on client-sponsored objects that were not initiated by the client through EPP. These operations may include contractual or policy requirements including, but not limited to, regular batch processes, customer support actions, Uniform Domain-Name Dispute-Resolution Policy (UDRP) orUniform Rapid Suspension (URS) actions, court-directed actions, and bulk updates based on customer requests. Since the client is not directly involved or knowledgable of these operations, the extension is used along with an EPP object mapping to provide the resulting state of the postoperation object, and optionally a preoperation object, with the operation metadata of what, when, who, and why. |
|
| |
| RFC 8591 | SIP-Based Messaging with S/MIME |
| |
|
|
Mobile messaging applications used with the Session InitiationProtocol (SIP) commonly use some combination of the SIP MESSAGE method and the Message Session Relay Protocol (MSRP). While these provide mechanisms for hop-by-hop security, neither natively provides end-to-end protection. This document offers guidance on how to provide end-to-end authentication, integrity protection, and confidentiality using the Secure/Multipurpose Internet MailExtensions (S/MIME). It updates and provides clarifications for RFCs3261, 3428, and 4975. |
|
| |
| RFC 8592 | Key Performance Indicator (KPI) Stamping for the Network Service Header (NSH) |
| |
| Authors: | R. Browne, A. Chilikin, T. Mizrahi. |
| Date: | May 2019 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8592 |
|
This document describes methods of carrying Key PerformanceIndicators (KPIs) using the Network Service Header (NSH). These methods may be used, for example, to monitor latency and QoS marking to identify problems on some links or service functions. |
|
| |
| RFC 8593 | Video Traffic Models for RTP Congestion Control Evaluations |
| |
| Authors: | X. Zhu, S. Mena, Z. Sarker. |
| Date: | May 2019 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8593 |
|
This document describes two reference video traffic models for evaluating RTP congestion control algorithms. The first model statistically characterizes the behavior of a live video encoder in response to changing requests on the target video rate. The second model is trace-driven and emulates the output of actual encoded video frame sizes from a high-resolution test sequence. Both models are designed to strike a balance between simplicity, repeatability, and authenticity in modeling the interactions between a live video traffic source and the congestion control module. Finally, the document describes how both approaches can be combined into a hybrid model. |
|
| |
| RFC 8594 | The Sunset HTTP Header Field |
| |
| Authors: | E. Wilde. |
| Date: | May 2019 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8594 |
|
This specification defines the Sunset HTTP response header field, which indicates that a URI is likely to become unresponsive at a specified point in the future. It also defines a sunset link relation type that allows linking to resources providing information about an upcoming resource or service sunset. |
|
| |
| RFC 8595 | An MPLS-Based Forwarding Plane for Service Function Chaining |
| |
| Authors: | A. Farrel, S. Bryant, J. Drake. |
| Date: | June 2019 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8595 |
|
This document describes how Service Function Chaining (SFC) can be achieved in an MPLS network by means of a logical representation of the Network Service Header (NSH) in an MPLS label stack. That is, the NSH is not used, but the fields of the NSH are mapped to fields in the MPLS label stack. This approach does not deprecate or replace the NSH, but it acknowledges that there may be a need for an interim deployment of SFC functionality in brownfield networks. |
|
| |
| RFC 8596 | MPLS Transport Encapsulation for the Service Function Chaining (SFC) Network Service Header (NSH) |
| |
| Authors: | A. Malis, S. Bryant, J. Halpern, W. Henderickx. |
| Date: | June 2019 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8596 |
|
This document describes how to use a Service Function Forwarder (SFF)Label (similar to a pseudowire label or VPN label) to indicate the presence of a Service Function Chaining (SFC) Network Service Header(NSH) between an MPLS label stack and the NSH original packet/frame.This allows SFC packets using the NSH to be forwarded between SFFs over an MPLS network. The label is also used to select between multiple SFFs in the destination MPLS node. |
|
| |
| RFC 8597 | Cooperating Layered Architecture for Software-Defined Networking (CLAS) |
| |
| Authors: | LM. Contreras, CJ. Bernardos, D. Lopez, M. Boucadair, P. Iovanna. |
| Date: | May 2019 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8597 |
|
Software-Defined Networking (SDN) advocates for the separation of the control plane from the data plane in the network nodes and its logical centralization on one or a set of control entities. Most of the network and/or service intelligence is moved to these control entities. Typically, such an entity is seen as a compendium of interacting control functions in a vertical, tightly integrated fashion. The relocation of the control functions from a number of distributed network nodes to a logical central entity conceptually places together a number of control capabilities with different purposes. As a consequence, the existing solutions do not provide a clear separation between transport control and services that rely upon transport capabilities.
This document describes an approach called Cooperating LayeredArchitecture for Software-Defined Networking (CLAS), wherein the control functions associated with transport are differentiated from those related to services in such a way that they can be provided and maintained independently and can follow their own evolution path. |
|
| |
| RFC 8598 | Split DNS Configuration for the Internet Key Exchange Protocol Version 2 (IKEv2) |
| |
| Authors: | T. Pauly, P. Wouters. |
| Date: | May 2019 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8598 |
|
This document defines two Configuration Payload Attribute Types(INTERNAL_DNS_DOMAIN and INTERNAL_DNSSEC_TA) for the Internet KeyExchange Protocol version 2 (IKEv2). These payloads add support for private (internal-only) DNS domains. These domains are intended to be resolved using non-public DNS servers that are only reachable through the IPsec connection. DNS resolution for other domains remains unchanged. These Configuration Payloads only apply to split- tunnel configurations. |
|
| |
| RFC 8599 | Push Notification with the Session Initiation Protocol (SIP) |
| |
| Authors: | C. Holmberg, M. Arnold. |
| Date: | May 2019 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8599 |
|
This document describes how a Push Notification Service (PNS) can be used to wake a suspended Session Initiation Protocol (SIP) User Agent(UA) with push notifications, and it also describes how the UA can send binding-refresh REGISTER requests and receive incoming SIP requests in an environment in which the UA may be suspended. The document defines new SIP URI parameters to exchange PNS information between the UA and the SIP entity that will then request that push notifications be sent to the UA. It also defines the parameters to trigger such push notification requests. The document also defines new feature-capability indicators that can be used to indicate support of this mechanism. |
|
