**Session Date/Time:** 22 Mar 2022 13:30

# intarea

## Summary

The intarea working group session covered a diverse set of individual contributions, ranging from proposals to reconsider the IETF's role in IPv4 maintenance and new approaches to IP packet structuring for efficiency, to discussions on internet address gaps, satellite network addressing, and the complex considerations around regional internet blocking. Three drafts explicitly requested working group adoption: "IPv4 Policing at the IETF", "IP Parcels", and "Internet Address Gaps". A proposal on "IP Regional Internet Blocking Considerations" received significant discussion, with the group ultimately advising against adoption at this time. Discussions highlighted ongoing technical challenges in networking and raised important questions about the IETF's scope and policy implications.

## Key Discussion Points

*   **IPv4 Policing at the IETF (Seth)**
    *   A new draft proposes IETF formally acknowledge and continue maintenance for IPv4, citing its historic stewardship, ongoing usage, and the lack of a clear IPv6 transition "end date."
    *   The draft was motivated by concerns raised in November about the appropriateness of IETF working on IPv4-specific fixes.
    *   The "lowest address fix" was highlighted as a local implementation fix with internet-wide benefits, not raising allocation policy issues.
    *   Discussion revolved around the definition of "serious" fixes for IPv4, whether IETF should only be in "maintenance mode" for IPv4 (bug/security fixes, no new development), and if a general consensus statement on IPv4 maintenance would genuinely help advance specific proposals.
    *   Concerns were raised that continued IPv4 effort could detract from IPv6 deployment.

*   **IP Parcels (Fred)**
    *   Introduced a new construct, "IP Parcels," allowing a single IP packet to carry multiple upper-layer protocol segments (a "packet of packets").
    *   The goal is to increase efficiency and performance for end systems and encourage larger MTUs across the internet.
    *   Based on jumbograms, it includes a Jumbo Payload Option (defined for IPv4 and IPv6) and can carry up to ~4MB.
    *   Leverages concepts like Generic Segment/Receive Offload (GSO/GRO) and IP fragmentation.
    *   A "parcel path qualification" mechanism (probes/replies) would determine network support.
    *   Discussion focused on whether this offers *additional* end-system efficiency beyond existing GSO/GRO/TSO and potential performance hits during initial deployment in heterogeneous networks.

*   **Internet Address Gaps (Luigi)**
    *   An update on two existing drafts (problem statement and gap analysis) that aim to stimulate community discussion on internet addressing.
    *   Key questions posed to the mailing list included desired internet features, where innovation is occurring (edge/core, protocol layers), and the fundamental nature of an "address."
    *   Feedback led to significant updates, including new sections on communication privacy, desired network features, a "system view on addresses," and discussions on ephemeral addresses and address semantics.
    *   Privacy emerged as a very important cross-cutting concern.

*   **IP Addressing for Satellite Higher Layer Address Aggregation (Zelin)**
    *   Presented challenges in applying current IGP/BGP/mobility protocols to fast-moving LEO satellite constellations.
    *   Proposed a "semantic addressing" scheme using three dynamic indices (Shear, Orbit Plane, Satellite Index) to uniquely identify satellites, with a potential 32-bit version for overhead saving.
    *   Advocated for a hybrid routing solution that leverages predictable satellite positions and computation in space, alongside traditional IGP for state detection.
    *   Discussion touched upon which operators are demanding such standardization (current solutions are proprietary) and the future role of shared satellite infrastructure.

*   **IP Regional Internet Blocking Considerations (Lenny)**
    *   A draft exploring technical approaches for blocking internet access to a country or region, motivated by recent geopolitical events.
    *   The document explicitly stated it does not advocate for or against blocking but aims to provide unbiased technical information for policymakers and the public.
    *   Reviewed known blocking techniques across physical, routing, packet, and DNS layers.
    *   Highlighted efficacy concerns and unintended consequences, such as empowering targeted regimes, the amoral nature of networks, and the difficulty of precise blocking due to the internet's decentralized design.
    *   Extensive discussion with strong feedback from the community:
        *   Concerns that the IETF is not the appropriate forum for such a document, as it lacks crucial policy and impact analysis that other bodies (e.g., Internet Society, Access Now) provide.
        *   Worries that even a neutral technical document could be misread as implicitly endorsing or codifying such actions.
        *   The IETF's role is often seen as keeping the internet connected and resilient, rather than documenting methods for disconnection.
        *   Suggestions to contribute expertise to existing policy-focused work or consider a longer-term, more politically aware approach.

*   **Higher Levels of Address Aggregation (Tony)**
    *   Revisited past discussions on CIDR and aggregation, focusing on reducing BGP routing table noise caused by leaking specifics for traffic engineering.
    *   Introduced concepts of "Abstraction Naming Boundary" (ISP border) and "Abstraction Action Boundary" (where aggregation actually happens, potentially multiple steps past the ISP).
    *   Proposed "unilateral remote aggregation" where a remote AS aggregates and advertises broader prefixes.
    *   Discussed potential benefits for IPv6 RIR allocations and the need for field input on optimal placement of aggregation boundaries to balance traffic engineering and routing table reduction.

*   **Service Routing in Multi-Access Edge Computing (MEC) (Zhongpang)**
    *   Proposed a mechanism for User Equipment (UE) to access local MEC services directly without a DNS procedure, aiming for lower latency.
    *   The UE would attempt a normal DNS request, but could also construct a destination IP address (e.g., by hashing the URL) to bypass DNS if successful.
    *   Concerns were raised regarding privacy violations (revealing URL path info) and potential IP address conflicts in a limited domain.

## Decisions and Action Items

*   **IP Regional Internet Blocking Considerations (Lenny)**: The working group did not reach consensus to adopt this document at this time. Authors are encouraged to review existing work by other organizations (e.g., Internet Society, Access Now) and consider engaging with other IETF research groups (e.g., HRPC) or forums that focus on policy and impact.

## Next Steps

*   **IPv4 Policing at the IETF (Seth)**: The chairs will initiate a working group adoption call on the mailing list.
*   **IP Parcels (Fred)**: The chairs will initiate a working group adoption call on the mailing list.
*   **Internet Address Gaps (Luigi)**: The chairs will initiate a working group adoption call on the mailing list.
*   For the remaining individual contributions, authors are encouraged to continue refinement and seek further feedback on the mailing list, as appropriate.