TIPTOP at IETF 126

22 July 2026
Grand Klimt Hall 1, Vienna, Austria

Chair(s):

Padma Pillay-Esnault (padma.ietf AT gmail.com)
Zahed Sarker (zaheduzzaman.sarker AT nokia.com)

Technical Advisor: Marc Blanchet (marc.blanchet AT viagenie.ca)
INT AD: Éric Vyncke (evyncke AT cisco.com)

Meeting: Session 1/1 (120 minutes)
Date: Wednesday, 22 July 2026
Time: 09:00–11:00 CEST, local meeting time
Meeting Room: Grand Klimt Hall 1

1. WG Document Status and Agenda Bashing

Padma Pillay-Esnault and Zahed Sarker

2. WG Documents

2.1 Key Characteristics, Use Cases and Requirements

Updates to draft-ietf-tiptop-usecase, Marc Blanchet

• Erik Kline: there was an effort to move out of bundle store and forward nomenclature. Is it done in the document?
• Marc Blanchet: editors made an effort in previous versions. please send comments if not ok.

2.2 An Architecture for IP in Deep Space

Updates to draft-ietf-tiptop-ip-architecture, Wesley Eddy

• Eric Vyncke: RIR Policy Guidance slide: keep requirements and potential approaches, but remove the RIR policy sentences
• Wesley Eddy: seems reasonable
• Zaheduzzaman Sarker: raise your hand to review document in the next weeks. Few (Éric Vyncke, Dan York, and Jorge Amodio) have agreed.

3. Non-WG Documents

3.1 Address Space Discussions

IP Address Space for Outer Space

draft-li-tiptop-address-space, Tony Li

• Rick Taylor: What happens if I travel from the Moon's orbit to the asteroid belt?
  • Tony Li: address-space wise, it does not matter. You will end up with a host route.
• Rick Taylor: I understand how this works technically. I do not understand how the geopolitics work here.
  • Tony Li: Trying to keep geopolitics out of this.
  • Tony Li: people coming all over to request address space. We just need a neutral party to take care of things. I don't care who it is.
• Jim Reid: Any thoughts on how RIR will authenticate requests, given a new chunk of address space is opened and could be exploited for various purposes. How does an RIR verify if the right person from say a space agency is requesting.
  • Tony Li: RIRs are very good at that already. They get requests all the time from various people.
  • Jim Reid: A few years ago, there was ENUM (telephone number mapping) and it was very difficult to find the right national authority.
  • Tony Li: telephone numbers are not allocated by RIRs

“My God, it’s full of RIRs!” / Address Space for Space

draft-kumari-tiptop-address-space, Warren Kumari

Joint Discussion

• Hans Petter Holen (RIPE NCC CEO): Offered clarification about RIPE's status. Better to use the current RIR structure.

• Kim Davies (IANA): Conflation between ideas and design and operational reality. Wants to see better division between the technical requirements and suggestion for how to implement with those proposals. Don't have an opinion on one or five RIRs or a middle ground. IANA would most likely between the IETF requirements and the policies and requirements. How do we define what success looks like?

  • Warren Kumari: feedback from IANA will be valuable
  • Tony Li: do something simple. Maybe 10 requests per year. does not need something fancy.

• Martin Duke: Clarification question - how do we think about the hierarchical nature of these locations/celestial bodies? How do you think about the further subdivision? Like Jupiter and moons and other celestial bodies.

  • Tony Li: Simple axiom in routing "addressing must follow topology"... but we don't know that topology yet. We need flexibility.
  • Warren Kumari: Fine if we have a few routes for a celestial body. Perfect aggregation is not often possible, but pretty good aggregation is just fine.
  • Martin Duke: I don't want to later be in a big problem because we haven't planned properly
  • Padma Pillay-Esnault: We need to think about relays, they might be serving multiple celestial bodies or systems. how they may interact.
  • Tony Li: we don't know the topology. need flexibility.
  • Warren Kumari: If Roscosmos need address space, they can't go to ARIN.
  • Tony Li: a single RIR then?
  • Warren Kumari: a single point of failure is not good
  • Tony Li: solving geopolitics is not in our charter

• Peter Koch: Separation of policy-making and policy-execution. These are not the addressing policies of our youth. It is not the globally routed IPv6 addresses. Need a different kind of allocation scheme. Cannot use the current structure of RIR. Who is the right body to decide this. Suggestion: submit a proposal to the IGF for a broader multistakeholder discussion.

  • Warren: I thought of NRO/ASOs/RIRs and their meetings. IGF may not have the right set of people.
  • Peter: How many of them live on different planets?
  • Peter: make sure we have the right people at IGF to discuss
  • Tony Li: One address space delegated to NRO. These are the right people to talk to.
  • Zaheduzzaman Sarker: we need to make sure to promote this discussion with the various stakeholders
  • Padma Pillay-Esnault: forwarders/routers in space will have more restrictions such as memory, compared to terrestrial Internet. We don't have all the answers, we need to provide some guidance from the technical standpoint.

• Erik Kline: Agrees with previous comments. Agree with an RIR structure. Skeptical a single prefix. There could be multiple. Skeptical of geographic aggregation, instead it will be based on the commercial agreements.

  • Padma Pillay-Esnault: We need to start somewhere. Encourages people to review.

• Jen Linkova: Number of routes does not change whatever the proposal.

  • Tony Li: simplify everybody if a single RIR
  • Jen Linkova: if organization does not have a process for this RIR, they have to start over.

• Tim Chown: Can the architecture document be IPv6-only? IPv4 routes is a slump.

  • Tony Li: IPv4 is opened to debate. Ipv4 has some advantages, such as lower overhead
  • Warren Kumari: agree with Jen.

• Lars Eggert: Maximize is a nice goal, but dangerous goal. Prefer to avoid bad solutions. Operational considerations may influence the outcome. Attempts to overload semantics on address space has been often bad. Flexibility is key here. Disagree with Peter to go IGF. The current Internet Governance model extend to space.

  • Tony Li: IPv4 global routing table is too large and IPv6 routing table is going in the same direction. We need to set our goals higher.

• Dan York: We need to be clear about IETF's role. We specify technical considerations and leave implementation to the IANA/RIRs and others to figure out the policies.

  • Tony Li: our goal is maximize aggregation. As soon as we have multiple allocators, we have less aggregation.
  • Warren Kumari: my concern of a single RIR is it won't be able to serve everybody.

Design Team Formation Discussion / Announcement

• Zaheduzzaman Sarker: need a design team?
• Tony Li: don't need a design team, need to make a choice
• Eric Vyncke: Ship the architecture document as RFC way before the IP addressing allocation is solved. One point however it should tell which address space to use: the global address space or another chunk.
• Padma Pillay-Esnault: may need an interim meeting to get everybody to attend and discuss.

3.2 QUIC Profiling

Evaluation of QUIC in Interplanetary Networks

draft-many-tiptop-quic-profile, Johannes Frisch

• Lars Eggert: packet loss rate is random or trying to model space links
  • Johannes Frisch: random
  • Lars Eggert: BBR has a link model. Is it the right model for space links? Capacity and transmission are scheduled in space: so Cubic would be filling more than BBR. Space links may not have the same loss patterns than random, so BBR may not be the right CC.
• Rick Taylor: Ready good and valuable work. Prof Carlo Caini had done similar work. Have you looked?
  • Johannes Frisch: saw it. related to QUIC as convergence layer for DTN.
• Jorg Ott: Comment: important to look at different implementations, as they behave differently. Does not concern you specifically but for the group.

Update to QUIC Profile

draft-many-tiptop-quic-profile, Marc Blanchet

• Lars Eggert: this is on track for adoption. Either before or after, make sure to profile QUIC that is compatible with what is used on Internet. For example, Padding may be seen as bad on spacec links, but sometimes they are needed. May need more nuance on the document. If a profiled implementation is able to talk to Google or Facebook or else on Internet, it will be a good indication that it follows the QUIC specifications.
  • Marc Blanchet: yes, we did test with Internet servers and it works. For padding, the RFC discuss that it could be used for fuzzing so that wiretapping is more difficult
  • Lars Eggert: There is no such thing about this in QUIC specifications
  • Marc Blanchet: yes, there is and I can quote you the text.
  • Lars Eggert: okay, but I'm not aware of somebody doing that. Nuance is required since Padding is required for initial handshake.
  • Zaheduzzaman Sarker: In my mind, there will be gateways and proxies, so a space-profiled-quic may not talk directly to Google.
  • Lars Eggert: I'm not talking about going over space links. A space-profiled-quic on Internet can talk to a non-space-profiled-quic.
  • Laurent Toutain: we are also working on QUIC header compression with SCHC. Will be discussed during the SCHC meeting on friday.
  • Tim Chown: like the draft. Security considerations about slow links denial of service attacks.
    • Marc Blanchet: maybe. It is an angle not looked at.
  • Zaheduzzaman Sarker: how many has read the document?
    • ~10 in the room. More remote. Quite good number of people read it.
  • Pool to adopt this as working group document?
    • Yes: 16; No: 2; No opinion: 22;
  • Zaheduzzaman Sarker: those who voted no, please tell us why?
    • nobody showed up
  • Zaheduzzaman Sarker: we have a rough concensus. We will put this on the list.

3.3 CoAP in Space

draft-gomez-tiptop-coap, Carles Gomez
* Carles Gomez: should the WG consider CoAP as work item, knowing it is not currently in the charter
* Padma Pillay-Esnault: not yet in the charter. it would be good to identify the use cases for this.
* Alexander Pelov: We used CoAP in LPWAN where we have severe delays and asymetric links, with intermittence of days. There can be cases, e.g. if the MOC needs to contact a single sensor on the board of a vessel, it may not need a full QUIC connection.
* Padma Pillay-Esnault: if one has to update multiple devices at the same time. Again, use cases are needed.
* Laurent Toutain: CoAP used for CoreConf, used for yang models in compact way, so useful in deep space context.

4.Interplanetary hops: Should path constraints be signaled to hosts?

Zaheduzzaman Sarker: not much time left. Alexander, please be quick.

draft-pelov-icmpv6-sec, Alexander Pelov

• Such a mechanism could be useful for example, to adjust the timers of a QUIC connection (or other). Or, if you have multiple prefixes on a celestial body, which cannot be routed directly and for some reason must go through an interplanetary link.

Decisions and Action Items

Decisions

• draft-ietf-tiptop-ip-architecture Update: Wesley Eddy will update the architecture draft to remove the policy-suggestive text regarding aggregation (per Éric Vyncke's AD feedback) to focus strictly on technical architectural requirements.

Action Items & Polls

• Adoption Poll for QUIC Profile: A formal poll was taken on the readiness of the QUIC Profile for deep space.
  • Question: "Do you think this document is ready for WG adoption?"
  • Result: yes: 16, no: 2, no_opinion: 22 (total: 86)
  • Action: The poll shows a strong majority of those expressing an opinion favor adoption. The chairs will take the adoption call to the mailing list to confirm working group consensus.

Next Steps

1.Chair's to take adoption call of draft-many-tiptop-quic-profile to the list.
2. Address Space Allocation Interim: Instead of forming a formal design team, the chairs will organize a dedicated virtual interim/side meeting specifically focused on the address space allocation problem. The objective is to define the technical requirements and success criteria for space address blocks, involving RIR representatives (NRO) and IANA, before submitting the technical requirements to the appropriate allocation authorities.
3. CoAP in Space Proposal: The authors of the CoAP proposal are encouraged to submit text mapping CoAP functionalities to the official TIPTOP use cases and use the mailing list for discussions.