IETF 126, Vienna
Wednesday, 22 July 2026, 14:00-15:30 CEST (Session III)
Room: Grand Klimt Hall 1
Chairs: Wassim Haddad, Carlos J. Bernardos
Note takers: David 'equinox' Lamparter, Ryo Yanagida
Draft agenda - subject to change.
Éric Vyncke (EV): looking for intarea AD! contact Éric about details
Tim Chown (TC): desperately lacking reviewers for intarea, contact
Tim/ADs about details
Jen Linkova (JL): regarding draft-ietf-intarea-rfc8335bis and
draft-ietf-intarea-extended-icmp-nodeid — one of them is blocking a 6man
draft, the other is needed for another draft. Emailed Bill to ask if he
has time/energy to keep progressing them; happy to take them over,
waiting for his response. Both have been stalled for a long time, likely
a resourcing issue rather than a technical one.
Fan Zhang (FZ) presents the slides.
No questions.
Carlos J. Bernardos (CB): WGLC will be started after the meeting.
Reminder: we need at least 5 reviews to move the document forward.
Remco van Mook (RM) presents the slides.
Lorenzo Colitti (LC): do you need to assign v4 addresses?
RM: No subnetting involved
LC: so v4 hosts may or may not be able to talk to each other?
RM: they can, through the gateway
LC: subnet mask is /32?
RM: yes
LC: might be useful to clarify the methods
LC: requirement to follow IPv6 routing changes as they come and go?
RM: yes
LC: ok, likely to be gotten wrong, ops simplifications might be a
tradeoff ... might prevent people from renumbering IPv6, kind of a
concern. Breaking v4 because of a bad implementation?
Tobias Fiebig (TF): appreciate the doc ... earlier work with DHCPv4o6
for nexthop, but that's a lot more DHCP, this is more elegant. There
will be some people that want v4.
Andrew Yourtchenko (AY): have to deal with the problem of splitting /28
across multiple routers, it's possible; unclear if changing hosts can be
done
RM: as long as the router reply to arp, completely unmodified host can
work. Incremental aspect is that you can remove arp down the line.
AY: is it guaranteed the routers will reply?
RM: yep
Ondřej Caletka (OC): The draft describes forward path from the host to
the network. What about the reverse path. How does the gateway find out
behind which IPv6 NH a particular IPv4 address sits?
RM: This is already part of draft-ietf-intarea-v4-via-v6, also the
working code has some example setup for dnsmasq on the gateway
side.
David Lamparter (DL): LC mentioned it might prevent renumbering the IPv6
network, how does that happen? nexthop is LL, no reference to GUA?
LC: The failure mode is that the application does a lookup once, and
doesn't follow. The LL might be a different router later, hardware gets
replaced.
RM: I've come across this already and is handled. And host-side should
not 'one-shot' the lookup. Setting an arp entry is the "poor" version
and needs updating.
LC: in a presence of legacy host, nothing is really saved. This can be
done purely by v4 today already.
RM: 'do nothing' approach is just use v4 as is but the elegance here
(...) End goal is to have v4 routes with actual v6 nexthop and ND.
LC: agree with the problem statement, perhaps we need to rethink the
solution
Saleem Bhatti (SB) presents the slides.
No questions
(skipped, no presenter)
Éric Vyncke (EV) presents the slides.
Tjeerd Pinkert (TP): Only 32 codepoints, on one hand true, but there are
categories. 2 categories are reserved, but in most implementation the
whole 7 bits are the identifier (not 5). Not giving out IP option
numbers would block future use. What would then be the criteria, e.g.
for a limited domain option? We want to actuall use this. Unhappily
surprised.
EV: there's a use case for IPPM if not mistaken. There's a document
about "no more work on v4". There are alternatives e.g. making a new
transport protocol that does not involve v4 Options. Answer depends on
IESG, can't provide that here. But believe other options should be
possible for the use case. Also, for limited domain, there are 4
experimental code points, use them if you have no choice.
Tom Hill (TH): Really like old hardware. Big problem is there is not
enough archiving. Please preserve information going defunct.
EV: Registries are kept, existing entries remain.
Richard Patterson (RP) presents the slides.
Ondřej Caletka (OC): if you have that example, 400MBit, link is capable
of much more, options for both v4 and v6 - what does that mean? 2x 400
MBit of v4 and v6 at the same time?
RP: talking about that in the document, are attempting to resolve the
race condition, not final yet (thinking about some priority to pick one
value), currently state for both.
OC: So both stack should keep track of this?
Stuart Cheshire (SC): there's a gap somewhere in this; slide says CPE
can't do queue management, how is it helpful to have the rate if the CPE
can't do queue management?
RP: might have put that poorly, device may just need to know bandwidth
to do anything useful?
SC: In the spirit of getting something working now, this might be a
topic for transport area rather than for intarea. Networking is a
complicated topic, so nobody should feel bad about not knowing
everything. To illustrate with an example, why doesn't your iPhone send
10Gb/s all the time? -> Because of transport protocols like TCP, QUIC,
WebRTC, etc. that adapt their sending rate based on ECN signals,
loss-based congestion control, etc. Enforcement does not have to be done
on entry to the subscriber link. Enforcement can be anywhere on the
path, and the eventual overall equilibrium behavior is the same.
RP: Enforcement is done at BNG.
SC: Right. This might be non-obvious; but it doesn't matter where on the
path the packet is marked, policing anywhere on the path results in
the desired end-to-end rate. It might seem intuitive that you should
police the packet rate on entry to the fiber link, but policing the
packet rate where the packets exit the fiber link has exactly the same
effect. You want to enforce traffic rate caps on hardware you own, not
hardware controlled by the customer, who could choose to disregard the
contracted traffic rate. When you discard traffic in excess of the
contracted rate senders learn from that and promptly reduce their
sending rate so that they don’t exceed the contracted rate. And
hypothetically, if a sender did not reduce its sending rate, then the
sender would just keep sending packets down the fibre that you promptly
discard on reception, which doesn’t hurt your network (it doesn’t wear
out the fiber) and doesn’t benefit the rogue user in any way, so there
is no incentive for any user to do that (but even if they did it
wouldn’t matter). Koen De Schepper has interesting work on a very
lightweight traffic shaper that can run at the receiving end of a fiber
link. Very cheap, very effective. See the SRM (Static Rate
Management) draft.
RP: Are you referring to future where everything is L4S?
SC: No, I'm referring to the way ISPs have performed rate management for
the last thirty years. This is not a new problem, and new solutions are
not needed. I'm happy to talk with you more in the break if that is
helpful.
Tim Winters (TW): DHCP hat: traditionally, we look at options, send them
to the other groups.
RP: steering away from transport, not telling the client what to do with
it, just providing the information.
TW: CPE side might be interesting, DHCP WG willing to help.
Éric Vyncke (EV): I think it's nice to do this at CPE.
RP: Thank you
Le Gai (LG) presents the slides.
Éric Vyncke (EV): (no hat) Have you looked at RFC 6169 (IP tunnel
considerations)?
EV: Good set of recommendations, 8 and 9 not really security issues,
should not be there?
LG: Disagree / asks back why EV thinks so.
EV: Let's discuss over emails
Tijeerd Pinkert (TP): Question on extension headers. If you drop packets
with extension headers, same as IPv4 world, EH framework becomes
completely unusable, probably partially already is. It was designed so
you can ignore what you don't need. Please take that into consideration.
Ke Xu (KX) presents the slides.
Timothy Winters (TW): RFC4443 has a magical line about checking packets;
some hosts may do that. It should work if we do check the packet. But
have question about other situations where it may not work.
Éric Vyncke (EV): (as individual) your challenge is a simple ICMP echo
request right?
KX: No, we use the marked [next?] packet
EV: I'll check the draft
If time permits:
Greg White (GW) presenting (3 minutes left in session).
Lorenzo Colitti (LC): might be better go to tsvwg? they'll suffer when
this doesn't work. Use of term reordering is quite confusing.
Total scheduled: 85 mins (90-min slot)