Internet Area Working Group (intarea) Internet Drafts

      
 IP Tunnels in the Internet Architecture
 
 draft-ietf-intarea-tunnels-15.txt
 Date: 09/05/2025
 Authors: Joseph Touch, Mark Townsley
 Working Group: Internet Area Working Group (intarea)
 This document discusses the role of IP tunnels in the Internet architecture. An IP tunnel transits IP datagrams as payloads in non- link layer protocols. This document explains the relationship of IP tunnels to existing protocol layers and the challenges in supporting IP tunneling, based on the equivalence of tunnels to links. The implications of this document updates RFC 4459 and its MTU and fragmentation recommendations for IP tunnels.
 Communicating Proxy Configurations in Provisioning Domains
 
 draft-ietf-intarea-proxy-config-08.txt
 Date: 14/10/2025
 Authors: Tommy Pauly, Dragana Damjanovic, Yaroslav Rosomakho
 Working Group: Internet Area Working Group (intarea)
 This document defines a mechanism for accessing provisioning domain information associated with a proxy, such as other proxy URIs that support different protocols and information about which destinations are accessible using a proxy. Discussion Venues This note is to be removed before publishing as an RFC. Source for this draft and an issue tracker can be found at https://github.com/tfpauly/privacy-proxy.
 Adding Extensions to ICMP Errors for Originating Node Identification
 
 draft-ietf-intarea-extended-icmp-nodeid-04.txt
 Date: 19/08/2025
 Authors: Bill Fenner, Reji Thomas
 Working Group: Internet Area Working Group (intarea)
 RFC5837 describes a mechanism for Extending ICMP for Interface and Next-Hop Identification, which allows providing additional information in an ICMP error that helps identify interfaces participating in the path. This is especially useful in environments where a given interface may not have a unique IP address to respond to, e.g., a traceroute. This document introduces a similar ICMP extension for Node Identification. It allows providing a unique IP address and/or a textual name for the node, in the case where each node may not have a unique IP address (e.g., a deployment in which all interfaces have IPv6 addresses and all nexthops are IPv6 nexthops, even for IPv4 routes).
 PROBE: A Utility for Probing Interfaces
 
 draft-ietf-intarea-rfc8335bis-01.txt
 Date: 21/07/2025
 Authors: Bill Fenner, Ron Bonica, Reji Thomas, Jen Linkova, Chris Lenart, Mohamed Boucadair
 Working Group: Internet Area Working Group (intarea)
 This document describes a network diagnostic tool called PROBE. PROBE is similar to PING in that it can be used to query the status of a probed interface, but it differs from PING in that it does not require bidirectional connectivity between the probing and probed interfaces. Instead, PROBE requires bidirectional connectivity between the probing interface and a proxy interface. The proxy interface can reside on the same node as the probed interface, or it can reside on a node to which the probed interface is directly connected. This document updates RFC 4884 and obsoletes RFC 8335.
 ICMP Extension Structure Length Field
 
 draft-ietf-intarea-icmp-exten-hdr-len-08.txt
 Date: 20/08/2025
 Authors: Ron Bonica, Xiaoming He, Xiao Min, Tal Mizrahi
 Working Group: Internet Area Working Group (intarea)
 The ICMP Extension Structure (RFC4884) does not have a length field. Therefore, unless the length of the Extension Structure can be inferred from other data in the ICMP message, the Extension Structure must be the last item in the ICMP message. This document updates RFC 4884 to define a length field for the ICMP Extension Structure. When length information is provided, receivers can use it to parse ICMP messages. Specifically, receivers can use length information to determine the offset at which the item after the ICMP Extension Structure begins.
 IPv4 routes with an IPv6 next hop
 
 draft-ietf-intarea-v4-via-v6-03.txt
 Date: 28/08/2025
 Authors: Juliusz Chroboczek, Warren Kumari, Toke Hoeiland-Joergensen
 Working Group: Internet Area Working Group (intarea)
 This document proposes "v4-via-v6" routing, a technique that uses IPv6 next-hop addresses for routing IPv4 packets, thus making it possible to route IPv4 packets across a network where routers have not been assigned IPv4 addresses. The document both describes the technique, as well as discussing its operational implications.
 The Multicast Application Port
 
 draft-ietf-intarea-multicast-application-port-01.txt
 Date: 13/09/2025
 Authors: Nathan Karstens, Stuart Cheshire, Mike McBride
 Working Group: Internet Area Working Group (intarea)
 This document discusses the drawbacks of the current practice of assigning a UDP port to each multicast application. Such assignments are redundant because the multicast address already uniquely identifies the data. The document proposes assigning a UDP port specifically for use with multicast applications and lists requirements for using this port. This method does not require modification to existing protocol stacks, though recommended updates to make the port easier to use are included.
 A YANG Data Model for ARP
 
 draft-ietf-intarea-arp-yang-model-00.txt
 Date: 16/10/2025
 Authors: Feng Zheng, Bo Wu, Robert Wilton, Fan Zhang, Yongqing Zhu, Xiaojian Ding
 Working Group: Internet Area Working Group (intarea)
 This document defines a YANG data model for the management of the Address Resolution Protocol (ARP). It extends the basic ARP functionality contained in the ietf-ip YANG data model, defined in RFC 8344, to provide management of optional ARP features and statistics.

data-group-menu-data-url="/group/groupmenu.json">

Internet Area Working Group (intarea)

WG Name Internet Area Working Group
Acronym intarea
Area Internet Area (int)
State Active
Charter charter-ietf-intarea-01 Approved
Document dependencies
Additional resources Issue tracker, Wiki, Zulip stream
Personnel Chairs Juan-Carlos Zúñiga, Wassim Haddad
Area Director Éric Vyncke
Mailing list Address int-area@ietf.org
To subscribe https://www.ietf.org/mailman/listinfo/int-area
Archive https://mailarchive.ietf.org/arch/browse/int-area/
Chat Room address https://zulip.ietf.org/#narrow/stream/intarea

Charter for Working Group

The Internet Area Working Group (INTAREA WG) acts primarily as a forum
for discussing far-ranging topics that affect the entire area. Such
topics include, for instance, address space issues, basic IP layer
functionality, and architectural questions. The group also serves as a
forum to distribute information about ongoing activities in the area,
create a shared understanding of the challenges and goals for the area,
and to enable coordination.

The Internet Area receives occasional proposals for the development and
publication of RFCs that are not in scope of an existing working group
and do not justify the formation of a new working group. The INTAREA WG
has a secondary role to serve as the forum for developing such work
items in the IETF. The working group milestones are updated as needed
to reflect the current work items and their associated milestones.

New work must satisfy the following conditions:

(1) WG consensus on the relevance for the Internet at large.

(2) WG consensus on the suitability and projected quality of the
proposed work item.

(3) A core group of WG participants with sufficient energy and
expertise to advance the work item according to the proposed
schedule.

(4) Commitment from the WG as a whole to provide sufficient
and timely review of the proposed work item.

(5) Agreement by the ADs, who, depending on the scope of the proposed
work item, may decide that an IESG review is needed first.

Milestones

Date Milestone Associated documents
Aug 2010 Submission of tunneling security issues document to the IESG as Info
Aug 2010 Submission of tunneling issues document to the IESG as Info
May 2010 Submission of IPID document to the IESG as PS