Repository navigation
Expand file tree
/
Copy pathWHATSNEW
More file actions
6614 lines (4909 loc) · 301 KB
/
Copy pathWHATSNEW
File metadata and controls
6614 lines (4909 loc) · 301 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
Recent changes in the INET Framework
====================================
INET-4.7.x (in development)
---------------------------
Notable backward incompatible changes are the following:
1. IEEE 802.11 rate control per receiver
IEEE 802.11 rate control now selects and adapts the transmission rate
separately for each peer a station transmits to. The rate controls previously
kept a single set of adaptive state per module, so the feedback of all peers
was blended into one rate.
To make this possible, the getRate() method of the IRateControl C++ interface,
implemented by AarfRateControl and OnoeRateControl, now takes the MAC address
of the receiver. This change requires the modification of rate control models
implemented outside INET, which no longer compile until their getRate() is
given the new argument. Simulation models that only configure a rate control
are unaffected.
Rate selection no longer consults the rate control for group-addressed frames,
which are never acknowledged and so could never have their rate corrected by
feedback. They now take a mandatory rate, as they already did when no rate
control was configured.
These changes may change the statistical results of simulations that use an
adaptive rate control, either where a station transmits to several peers or
where it sends group-addressed traffic.
2. IEEE 802.11 wire and reception corrections
QoS Control fields now use the standard bit positions. Non-QoS Data no
longer aliases the QoS TID-0 duplicate cache. OFDM radios generate and check
SIGNAL parity and reject undefined RATE codes; HR/DSSS and ERP transmissions
carry their specific PHY protocol identities.
AP beacon intervals are rounded down to whole 1024-us TUs for both target
scheduling and advertisement (100ms becomes 99.328ms). Configured intervals
must be between 1 and 65535 TUs. Beacon and Probe Response frames now encode
the DSSS Current Channel for 2.4 GHz operation. Their channelNumber field is
a standard channel number, with -1 for an absent element, rather than an
internal channel index. Radio channel parameters and scan results remain
internal indices. Custom frame producers should follow the migration guide.
The mesh no-forwarding-information reason code is corrected from 60 to 62.
These corrections change affected packet bytes and may change Wi-Fi
simulation trajectories and fingerprints.
Noncompliant layered OFDM retains its configured mode and RATE-0 placeholder;
SIGNAL parity is checked in both compliant and noncompliant operation.
3. UDP no longer reports a received datagram twice
The Udp module emitted packetReceivedFromLower a second time for every datagram
it received from the network layer. Its base class, LayeredProtocolBase, already
emits the signal before it calls handleLowerPacket, and Udp emitted it again in
processUDPPacket. Every other protocol module emits it once.
No statistic changes, because Udp.ned declares the signal and sources no
statistic from it. Code that subscribes to the signal on a UDP module is
affected: it now runs once per datagram instead of twice, so a listener that
counted arrivals or summed bytes reported twice the true value and now reports
the true one.
4. Resending accepts the packets that a producer offers
The canPushPacket() method of the Resending protocol element tested its packet
argument instead of the packet that the module holds, so it refused every
packet that a producer asked about. An active producer that asks before it
pushes, for example a PacketServer after a queue, therefore never passed a
packet to Resending. Resending now accepts a packet whenever it holds none, as
its canPushSomePacket() method already did.
This changes the results of simulations that feed Resending from such a
producer. Inside INET, the client in the Network6 and Network7 steps of
tutorials/protocol now sends its packet; before, it sent none.
5. An unrecognized ICMP or ICMPv6 type is discarded, not thrown
Icmp::processIcmpMessage and the ICMPv6 type switch each had a default branch
for a message type they do not know, and each branch threw a cRuntimeError.
Any peer could therefore end a simulation with one packet.
RFC 1122 section 3.2.2 and RFC 4443 section 2.4(b) both require a silent
discard. Both branches now emit packetDropped and delete the packet. A
simulation that used to stop with "Unknown ICMP type" carries on.
No baseline moves. A scenario that reached either branch aborted, so it cannot
be in a passing fingerprint or statistical baseline.
6. IPv6 reassembly writes the payload length of the reassembled datagram
Ipv6FragBuf::addFragment rebuilt the datagram from the base header of the
first fragment and left its Payload Length field untouched, so the field
described that fragment and not the datagram.
Where the field exceeded the reassembled data, Ipv6::decapsulate asserted and
the run stopped. Where it fell short, which is the ordinary two-fragment case,
the same function truncated the datagram silently to the first fragment's
length. Every IPv6 reassembly was affected. The field now counts every octet
after the base header, extension headers included, as RFC 8200 section 3
requires.
The same function also erased a stale end() iterator when one fragment
completed a datagram, which aborted the run on an atomic fragment.
Simulations that reassemble IPv6 fragments deliver whole datagrams now, so
their trajectories and fingerprints may change.
7. ICMPv6 drops an error report for a protocol nothing registered
Icmpv6 handed the error indication up to the protocol the quoted datagram
names without asking whether anything on the node had registered it. The
MessageDispatcher then knew no route and stopped the run, so any node could be
halted by an ICMPv6 error about a protocol it does not run.
Icmpv6 already kept the set of registered transport protocols and never read
it. It reads it now and drops the report, as Icmp has always done for IPv4.
8. No ICMP or ICMPv6 error about a link-layer broadcast or multicast
Icmp::maySendErrorMessage and Icmpv6::validateDatagramPromptingError each
suppressed an error report for four conditions, and every condition read an IP
address. RFC 1122 section 3.2.2 and RFC 4443 section 2.4(e) also forbid a
report about a datagram that arrived in a link-layer broadcast or multicast
frame, which no IP address records.
Both functions read the MacAddressInd tag of the arriving frame now. A node
that receives a unicast-addressed datagram inside a broadcast frame, for a
closed port or an unknown protocol, stays silent instead of answering the
address in the source field.
Simulations where that happens send fewer ICMP messages, so their
trajectories and fingerprints may change.
9. IPv6 fills in two length fields it used to leave wrong
A Packet Too Big report carried an MTU of zero. Icmpv6::sendErrorMessage took
no MTU and handed createPacketTooBigMsg a literal 0, under a bare "TODO
implement MTU support". It takes one now, and Ipv6 passes the MTU it has
already read from the outgoing interface two lines above the call, as RFC 4443
section 3.2 requires. A source that receives the report can act on it.
Every fragment of a fragmented datagram carried the Payload Length of the
whole datagram, because Ipv6::fragmentAndSend builds each fragment from a copy
of the base header. Each fragment now carries its own: the fragment header
plus that fragment's share.
Simulations that fragment IPv6 datagrams or report a too-big packet put
different bytes on the wire, so their fingerprints may change.
10. IPv4 verifies the header checksum, and reassembly reads the protocol
Ipv4 dropped a datagram whose header checksum failed only when the header was
also structurally incorrect: the guard read "!isCorrect() && !verifyChecksum()"
and an AND short-circuits, so a well-formed header never reached the checksum
test and a wrong checksum was accepted. The guard is an OR now, which is what
RFC 1122 section 3.2.1.2 requires.
Ipv4FragBuf::Key, the reassembly key, carried three of the four fields RFC 791
names: source, destination and identification, but not the protocol. Fragments
of two datagrams that shared an identification but used different protocols
reassembled into each other. The key carries the protocol now.
Simulations with header bit errors drop more datagrams than before, and
simulations that fragment two protocols at once reassemble them apart, so
fingerprints for those scenarios may change.
11. An ARP packet a host cannot process is discarded, not thrown
Arp::processArpPacket stopped the run in two places a neighbour controls. Its
opcode switch threw on any operation the model does not implement, and RFC
5494 section 3 makes 24 and 25 legal values a neighbour may put on a link. And
it peeked the packet with the default flags, which turns an incorrect chunk
into an error; the serializer marks a packet incorrect when its hardware space
is not Ethernet or its protocol space is not IPv4, so nothing ever read that
mark.
Both now end processing, as RFC 826 states: the unknown opcode breaks out of
the switch after the table step, and the unsupported space is dropped with a
packetDropped signal. The two RARP branches still throw, which the model means
as a statement that it does not implement RARP.
12. TCP takes its first round-trip measurement as RFC 6298 states
rttMeasurementComplete folded the first measurement into the recurrence of
RFC 6298 section 2.3, starting from srtt = 0 and rttvar = 3/4. The first
smoothed value was therefore one eighth of the measurement and the first
timeout described the initial guess rather than the path.
Section 2.2 gives the first measurement a case of its own: SRTT = R and
RTTVAR = R/2. The estimator now does that, and a new rttMeasured flag in the
algorithm state tells the two cases apart.
Every TCP connection's early retransmission timeout changes, so trajectories
and fingerprints of TCP simulations move with it.
13. QUIC closes the connection on an unknown frame type, and a server pads its
Initial datagram
A frame of a type the model does not know threw a cRuntimeError, so any peer
could stop a run with one frame. RFC 9000 section 12.4 makes it a connection
error of type FRAME_ENCODING_ERROR, and the model now sends CONNECTION_CLOSE
with that code. Two further stops sat behind it: the frame loop read on past
the error into bytes that are no frame header, and the datagram loop then
read those bytes as a packet header. Both stop when a connection error is
raised.
PacketBuilder::buildServerInitialPacket did not pad. RFC 9000 section 14.1
requires a server to expand a datagram carrying an ack-eliciting Initial
packet to at least 1200 octets, which the client's builder has always done.
14. DHCP corrects seven defects in its client and server
The client drew a new transaction identifier for every DHCPREQUEST, so a
request never carried the identifier of the offer it answered, against RFC
2131 section 4.4.1. It keeps the identifier of the exchange now, and a new
transaction draws its own.
The server wrote three field values it had no right to write. It put the
gateway address into the giaddr of a DHCPOFFER, where RFC 2131 table 3 wants
the giaddr of the client's DHCPDISCOVER; it put the leased address into the
ciaddr of a DHCPACK, where the table allows only the client's ciaddr or zero;
and it wrote a constant false into the flags of every reply, where the table
wants the flags of the message it answers. It also returned a domain name
server option holding 0.0.0.0, because nothing in the model ever assigns that
field.
The server stayed silent for a DHCPREQUEST naming an address of a foreign
subnet, because it asked its lease table before it asked about the subnet and
a foreign address is in no table. RFC 2131 section 4.3.2 wants a DHCPNAK.
The client's retransmission delay was a constant 60 seconds, and it never
repeated a DHCPREQUEST at all: it abandoned the transaction at the first
timeout. RFC 2131 section 4.1 asks for a randomized exponential backoff, 4
seconds doubling to 64, and section 3.1 asks for the request to be repeated.
Both are there now, for the initial exchange only: RENEWING and REBINDING keep
the schedule of section 4.4.5.
DHCP exchanges now take different times and put different bytes on the wire,
so trajectories and fingerprints of simulations that use DHCP move.
15. A DHCP client checks the granted address before it takes it
RFC 2131 section 4.4.1 asks a client to check that the address it was granted
is not already in use, and RFC 5227 section 2.1.1 makes that check an ARP
Probe. The client now sends one, waits probeWait (1s by default; 0s turns the
check off), and takes the address only if nobody answers. If somebody does, it
sends a DHCPDECLINE and starts again. It probes only an address it is about to
start using, after REQUESTING or REBOOTING, and only on a link that uses ARP.
Three of the four pieces this needed were already written and unreachable.
Arp::sendArpProbe had no caller, DhcpClient::sendDecline had no caller, and
Arp::processArpPacket threw "wrong ARP packet: source IPv4 address is empty"
on the very packet a probe is, so a neighbour's lawful probe stopped the run.
An all-zero sender protocol address marks a probe: it claims nothing, so the
table steps are skipped for it and the target question still gets its answer.
Arp gained an arpAddressConflictDetected signal. A reply to a probe is
addressed to the all-zero sender address, so the target question cannot
recognize it; Arp remembers what it is probing and matches the reply by its
sender protocol address instead.
IArp gained a pure virtual sendArpProbe, which DhcpClient calls. An IArp
implementation outside INET must override it; the migration guide says how.
GlobalArp overrides it with an empty body, because it has nobody to ask.
DhcpClient gained an arpModule parameter and a probeWait parameter.
DHCPDECLINE now carries the server identifier, which RFC 2131 table 5
requires.
DhcpServer marks a declined address unavailable, which RFC 2131 section 4.3.3
makes a MUST. Without it the server offered the same address again and the
client declined again for the whole run.
Every DHCP client now spends probeWait between the acknowledgement and taking
the address. The lease timers T1 and T2 are armed when the acknowledgement
arrives, so renewal timing does not move; traffic from the client starts one
probeWait later.
16. IEEE 802.11 management recovery belongs to each EDCAF
Management failures and completion now update the contention window and
retry state of the affected access category. Previously the shared recovery
procedure changed the best-effort window even for voice management frames.
The hcf.edca.mgmtAndNonQoSRecoveryProcedure module moves beneath each
edcaf[i], and its C++ getter moves from Edca to Edcaf. Update configuration,
signal subscriptions and result paths as described in the migration guide.
Management-recovery trajectories may change, including Block Ack agreement
negotiation. The MacQosWithBlockAck example fingerprints are updated; the
QoS and NonQos showcase fingerprint controls remain unchanged.
17. IEEE 802.11 PHY mode properties for response-rate selection
The physical layer (PHY) mode interface now exposes the mode family,
legacy preamble type, and non-HT reference rate. Custom rate selectors can
query these properties without a dependency on a concrete mode class.
HT means High Throughput; VHT means Very High Throughput. The reference rate
for HT and VHT modes depends on the modulation and code rate of stream 1.
An unsupported reference-rate mapping returns bps(NaN), where NaN means
not a number.
IIeee80211Mode gains three pure virtual methods: getModulationClass(),
getLegacyPreambleType(), and getNonHtReferenceRate(). Direct implementations
outside INET must implement these methods before they compile again.
Ieee80211ModeBase supplies default unknown values for custom subclasses.
The migration guide explains the return values and required overrides.
18. IEEE 802.11 radio commands wait for an accepted frame
Tx is the component that transmits frames for medium access control (MAC).
Radio reconfiguration now waits until Tx completes an accepted transmission.
This includes the short interframe space (SIFS) before a response.
The MAC previously used only the medium state, which cannot identify that wait.
For example, a radio command arrives while Tx waits to transmit an
acknowledgment (ACK) frame. The MAC keeps the command until the ACK completes.
This prevents radio reconfiguration before the accepted response completes.
The change affects event order and the event fingerprints of IEEE 802.11 simulations.
Custom implementations of ITx must implement hasTransmission() before they compile again.
The method identifies both the wait before transmission and the transmission itself.
The migration guide explains the return values and the order of the completion callback.
Notable backward compatible changes are the following:
1. IEEE 802.11 per-station rate statistics
The datarateChanged signal of the rate controls is now emitted with the name of
the receiving station as a named details object, and a new dataratePerStation
statistic demultiplexes it into one data rate vector per peer. The
datarateSelected signal of Dcf and Hcf is tagged the same way, which also covers
fixed and configured rates. The declaration of the aggregate datarateChanged
statistic is unchanged and it still ignores the details, but the values it
records move: the rate control no longer reports a rate when the mode set
changes, and reports one per station when that station is first seen instead.
2. IEEE 802.11 per-receiver configured data frame rates
RateSelection and QosRateSelection gained a dataFrameBitratePerReceiver
parameter, a map from peer interface module path to bitrate, which fixes the
rate of originated unicast data frames separately for each peer. It is empty by
default, so it changes nothing unless it is configured. The dataFrameBitrate
parameter, which fixes one rate for the whole interface, is unchanged.
3. Naming the host owning a MAC address
A new L3AddressResolver::getHostNameWithMacAddress() method names the host that
owns a MAC address, by the host's path relative to the network, and falls back
to the MAC address string when no host owns the address.
4. Type-aware field chunk serializers
FieldsChunkSerializer gained two protected hooks, serializeFields() and
deserializeFields(). The deserializeFields() hook receives the concrete chunk
type that was requested from ChunkSerializerRegistry, so a serializer that is
registered for several chunk types can build the exact requested type. The old
hooks, serialize(stream, chunk) and deserialize(stream), are deprecated but
still work: they are no longer pure virtual, and the new hooks call them by
default. Serializers written against an earlier INET version need no source
change. See the migration guide for the new signatures.
5. Region tag removal by type
The removeTagsWherePresent() method of SharingRegionTagSet removed the region
tags of every type in the given range, and not only the tags of the requested
type. It now removes only the requested type, as its documentation always
stated. The same correction reaches Chunk::removeTagsWherePresent() and
Packet::removeRegionTagsWherePresent(), which forward to it. The clearTags()
method gained an optional predicate that selects the tags to clear, and clears
all of them by default, so its own behavior is unchanged.
This may change the results of a simulation that removes the region tags of one
type while the region tags of another type cover the same range. Inside INET
this happens when ResidenceTimeMeasurer ends a measurement: it removed the
ResidenceTimeTag and, with it, the FlowTag and the PacketEventTag of the packet.
Those two tags now survive the measurement.
6. IEEE 802.11 MIB rate state and notifications
The Management Information Base (MIB) now stores supported, basic, and
operational rate sets for the local station, Basic Service Set (BSS), and
individual peers. A rate set distinguishes unknown information from a
known empty set. Rate-set setters validate the input before they commit it.
A combined BSS and peer update installs both records before one notification.
The rateStateChanged signal reports a committed rate, High Throughput (HT)
capability, or channel-operation change. Its value is true, with no details
object. Listeners query the MIB for current state. Equal rate-set updates
emit no signal. The migration guide explains state access and listener use.
Association release and bulk teardown remove both peer HT capabilities and
rate sets before one notification. A listener can install replacement peer
state from the callback; teardown does not remove that replacement.
Direct HT or rate removal still emits its own notification if state changes.
Empty teardown emits no signal. Existing configuration parameters stay unchanged.
INET-4.7 (July 2026) — feature release
--------------------------------------
This is a new feature release in the INET 4.x branch. The central theme of this
release is the maturation of the IPv6 protocol family, bringing it substantially
closer to feature parity with IPv4. Highlights include a new declarative IPv6
network configurator, IPv6 multicast routing (MLD, and PIM-DM/PIM-SM over IPv6),
node lifecycle support, Duplicate Address Detection, a modernized Mobile IPv6
(MIPv6) model with new Proxy Mobile IPv6 (PMIPv6) support, and IPv6 support in
BGP (MP-BGP) and IPsec. Outside the IPv6 area, the release brings satellite and
GNSS track mobility models with geographic visualization, a substantial overhaul
of the STP and RSTP spanning tree models, major BGP improvements, TCP Path MTU
Discovery, and a configurable RNG grouping mechanism. The release also contains
numerous smaller improvements and bug fixes. Requires OMNeT++ 6.4 or later.
For a complete list of all added, removed, and changed folders, NED modules,
packet chunks, packet tags, statistics, C++ classes, and signals, please refer to
the ChangeLog file in the src folder.
Notable backward incompatible changes are the following:
1. Mobile IPv6 (MIPv6) modernization
The Mobile IPv6 model was substantially modernized and aligned with the rest of
the IPv6 stack. The module previously named xMIPv6 was renamed to Mipv6, and the
xMIPv6Support wrapper was flattened into Ipv6NetworkLayer, with Mobile IPv6 now
enabled by a hasMipv6 switch.
IPv6 tunneling was reworked to follow the same model as IPv4: a tunnel is now
represented as a virtual network interface rather than a dedicated mechanism,
and the former Ipv6Tunneling module was removed. MIPv6-specific per-interface
state was moved out of Ipv6InterfaceData into a separate Mipv6InterfaceData
class.
Several new roaming scenarios were added, and a number of latent correctness
bugs in binding management, return routability, and route optimization were
fixed along the way.
This change requires the modification of simulation models that reference the
xMIPv6 module type, the Ipv6Tunneling module, or the xMIPv6Support submodule
path, as well as C++ code that accesses MIPv6 fields through Ipv6InterfaceData.
2. STP and RSTP overhaul
The Spanning Tree Protocol (STP) and Rapid Spanning Tree Protocol (RSTP) models
were substantially reworked for correctness and standards compliance. RSTP now
implements the full Proposal/Agreement handshake for rapid, timer-free
transition to the forwarding state. Several long-standing defects were fixed,
including a topology-change (TCN) BPDU storm, a hold-timer violation, and
incorrect timer interval assignments. The nonstandard ALTERNATE port role, which
had been backported from RSTP, was removed from STP.
A number of NED parameters and packet types were renamed for clarity and
consistency. Notably, the RSTP helloTime parameter was renamed to helloInterval,
and the STP maxAge parameter was renamed to configuredMaxAge (with the former
currentMaxAge becoming maxAge). The BPDU packet type names were also reworked
(e.g. stp-hello, rstp-hello).
In addition, when the port path cost is not explicitly configured,
L2NetworkConfigurator now derives the default from the link speed, following
the recommendation of IEEE 802.1D-2004.
This change requires the modification of simulation models that configure the
renamed parameters, and it may significantly change the statistical results of
spanning tree simulations due to the corrected protocol behavior.
3. IPv6 Router Advertisement interval defaults
The default Router Advertisement interval was changed to follow RFC 4861.
Previously, the minIntervalBetweenRAs and maxIntervalBetweenRAs parameters
defaulted to very short, Mobile-IPv6-tuned values (30 ms and 70 ms) and were
additionally overridden for wireless interfaces. They now default to the
standard RFC 4861 values, and the wireless special-casing was removed.
This change doesn't require the modification of simulation models, but it may
significantly change the statistical results of IPv6 simulations that relied on
the previous fast Router Advertisement timing, particularly those involving
wireless or mobile nodes.
4. IPsec generalization to IPv6
The IPsec model, introduced in the previous release for IPv4, was generalized
to be address family independent, and now supports IPv6 as well. Traffic
selectors and the security association and policy databases operate on
generic L3 addresses, each IPsec instance serves the address family of its
enclosing network layer, and Ipv6NetworkLayer gained a hasIpsec switch
analogous to the IPv4 one. AH and ESP headers are treated as terminal headers
in the IPv6 extension header chain. Two latent bugs in AH protection (a
zero-length header on egress, and a double header removal on ingress) were
fixed, and a new example demonstrates ESP over IPv6.
As part of this change, the model was moved from the networklayer/ipv4/ipsec
folder to networklayer/ipsec, with the NED package changing accordingly. This
change requires the modification of simulation models and C++ code that
reference the old package or include paths.
5. BGP timer configuration
The BGP timers, previously configured via the <TimerParams> element of the
bgpConfig XML file, are now parameters of the Bgp module (connectRetryTime,
holdTime, keepAliveTime, startDelay). A <TimerParams> element in the XML
configuration is now rejected with an error message that explains how to
migrate.
This change requires the modification of simulation models that configure
BGP timers in the XML configuration file.
6. ICMP error indication refactoring
The handling of ICMP error indications was refactored into a properly layered
architecture in which each protocol layer processes only its own header. As part
of this, the IcmpErrorInd indication and the IcmpErrorTag tag were each split
into IPv4-specific and IPv6-specific variants (Icmpv4ErrorInd / Icmpv6ErrorInd
and Icmpv4ErrorTag / Icmpv6ErrorTag).
These changes are backward incompatible for C++ code that directly references
the old combined ICMP error indication or tag types.
Notable backward compatible changes are the following:
1. IPv6 network configurator
A new Ipv6NetworkConfigurator, with a companion Ipv6NodeConfigurator, was added,
bringing the declarative, IPv4-style network configuration approach to IPv6.
Like its IPv4 counterpart, it assigns addresses and sets up routing tables
automatically based on the network topology, while allowing fine-grained control
through an XML configuration. Explicit per-interface addresses can be assigned
(e.g. using a prefix::interface-id form), overriding the default EUI-64 interface
identifier. Both the IPv4 and IPv6 configurators now also accept CIDR
"address/prefixlen" notation in static route specifications, and gained
addRemoteRoutes and addManualRoutes parameters that allow the individual
route generation steps to be enabled or disabled separately. The simpler
Ipv6FlatNetworkConfigurator remains available.
2. IPv6 lifecycle and multicast forwarding
The IPv6 protocol stack gained node lifecycle support, so that IPv6 nodes now
correctly handle shutdown, restart, and crash operations the same way IPv4 nodes
do. In addition, IPv6 multicast packet forwarding was implemented, including a
multicast routing information base and forwarding information base with reverse
path forwarding (RPF) checks. Together with the multicast routing protocols
described below, this enables IPv6 multicast scenarios that were previously only
possible with IPv4.
3. Multicast Listener Discovery (MLD)
IPv6 multicast group membership is now managed using the Multicast Listener
Discovery protocol. The MLDv1 router-side behavior was completed, and a new Mldv2
module implementing MLDv2 (RFC 3810) was added, including the corresponding
message set, serializer, packet dissector, and printer; the MLD version is
selected by module typename. Source-specific multicast (SSM) membership state was
added to Ipv6InterfaceData. The IPv4 IGMPv3 model was brought to lockstep parity
with MLDv2 (query and report retransmission, interoperation with older versions),
so that the IPv4 and IPv6 multicast membership implementations now mirror each
other.
4. PIM over IPv6
The PIM-DM and PIM-SM multicast routing protocols were generalized to be address
family independent, operating on generic L3 addresses, and can now run over IPv6
in addition to IPv4, while the existing IPv4 PIM behavior is preserved unchanged.
The new MulticastRouter6 node type provides a ready-to-use pure-IPv6 multicast
router. PIM-SM can also derive the rendezvous point per group from embedded-RP
IPv6 addresses (RFC 3956). Source-specific multicast (SSM, RFC 4607) is now
fully supported on both address families: source-list memberships from
IGMPv3 (IPv4) and MLDv2 (IPv6) drive PIM-SM to build RP-less, source-rooted
(S,G) trees for groups in the SSM range, using INCLUDE-only semantics and
requiring no rendezvous point. The PIM packet serializer was extended to support
the IPv6 encoded-address forms.
5. IPv6 Neighbor Discovery
IPv6 Neighbor Discovery was extended in several backward compatible ways.
Duplicate Address Detection (DAD) is now performed for autoconfigured global
addresses in accordance with RFC 4862, and ICMPv6 Redirect message sending and
processing was implemented (RFC 4861). Further Router Advertisement and Neighbor
Discovery parameters were exposed as NED parameters and XML configuration
attributes, and node bootstrap delays became configurable. A new sendRedirects
parameter on the Ipv6 module allows suppressing Redirect messages, which is
useful on wireless ad-hoc networks.
6. Proxy Mobile IPv6
Support for Proxy Mobile IPv6 (PMIPv6, RFC 5213) was added. PMIPv6 provides
network-based mobility management: the network tracks the movements of a
mobile node and keeps its IPv6 address stable across handovers, without
requiring any mobility support in the mobile node itself. The new Pmipv6
module implements both the Local Mobility Anchor (LMA) and the Mobile Access
Gateway (MAG) roles, using Proxy Binding Update / Acknowledgement signaling
based on the Mobile IPv6 message formats, and tunneling between the MAGs and
the LMA. A new example demonstrates a handover in a PMIPv6 domain, with the
mobile node keeping its address across the move.
7. IPv6 netfilter hooks
The Ipv6 module now provides the same set of netfilter-style hooks as its
IPv4 counterpart: the LOCALIN hook is now invoked on local delivery, the
FORWARD hook was added, and packets can be reinjected at all five hook points
after asynchronous processing. This allows C++ modules such as reactive
routing protocols to interpose on the IPv6 datapath in the same way as with
IPv4.
8. BGP improvements
The BGP model received major improvements in several areas. BGP now supports
IPv6: sessions can be established over IPv6 TCP connections, and IPv6 routes
are exchanged using the multiprotocol extensions (MP-BGP, RFC 4760),
including multiprotocol capability negotiation in the OPEN message (RFC 5492)
and serialization of the MP_REACH_NLRI and MP_UNREACH_NLRI path attributes.
Related fixes make iBGP work over a multi-hop IGP with IPv6, and new examples
demonstrate EBGP over IPv6 and BGP running on top of an OSPFv3-based IGP.
BGP is now lifecycle-aware: node shutdown, restart, and crash operations are
handled properly, with sessions re-established and routes re-learned after a
restart. A new Adj-RIB-In data structure stores all routes learned from
peers, and the decision process is re-run when a route is withdrawn, so that
an alternative route can take its place. New examples demonstrate route
withdrawal and failover scenarios.
Session management robustness was also improved: routers now use a single
shared listening socket, connection collision detection was implemented
according to RFC 4271, several errors in connection retry and reconnection
handling were fixed, and BGP sessions are shut down gracefully on node
shutdown.
The BGP lifecycle support and the Adj-RIB-In extension were contributed by
Giovanni Nardini.
9. Satellite mobility and geographic visualization
New mobility models and visualizers support simulating satellite networks
and other scenarios placed on the Earth's surface. The new SatelliteMobility
module computes satellite positions from standard TLE (two-line element)
orbital data using the SGP4 propagation model, and GnssTrackMobility replays
position tracks recorded by GNSS (GPS) receivers. The underlying geometry
library was extended with WGS84 geodesy, Earth-centered (ECEF) coordinate
systems, and an equirectangular map projection.
On the visualization side, the new GeoMapCanvasVisualizer draws a world map
with a graticule as the scene background, GeoHorizonCanvasVisualizer draws
the visibility footprint of satellites on the map, and
GeoSkyViewCanvasVisualizer displays an azimuth/elevation sky view plot next
to observer nodes. The mobility visualizer was extended with 3D orientation
display and direction projection modes, movement trails handle the
antimeridian correctly, and several visualizers now clip their drawings to
the map area. Mobile nodes can display their geographic position using the
{geo_position} directive of displayStringTextFormat. A new example
demonstrates satellites moving above a map of the Earth.
10. TCP Path MTU Discovery
The TCP model now implements Path MTU Discovery (RFC 1191 and RFC 1981), allowing
connections to discover and adapt to the largest packet size that can traverse
the path without fragmentation. In addition, TCP now forwards ICMPv4 and ICMPv6
error indications to the application as soft notifications, and aborts
connections in the SYN_SENT state on hard ICMP errors.
11. RNG grouping
A new GroupedRngManager was added, providing a flexible way to share random
number generators among simulation components. It supports grouping components by
module (the default, one RNG set per module), by node (a node-wide shared RNG
set), or network-wide (a single global RNG set), selectable via the rng-grouping
configuration option.
12. OSPFv3 packet serializer
A packet serializer was added for OSPFv3, enabling OSPFv3 packets to be
recorded into PCAP files, sent through emulation interfaces, and verified
byte by byte in fingerprint tests. Several packet format errors (incorrect
packet and LSA length fields) were fixed in the process, and the Ospfv3
module gained a checksumMode parameter for RFC-correct checksums.
13. STP/RSTP tutorial
A new tutorial introduces the Spanning Tree Protocol and Rapid Spanning Tree
Protocol through a progression of examples, demonstrating root bridge election,
port roles and states, topology change handling, and the rapid transitions
provided by RSTP.
14. Documentation refinements
The IPv6 chapter of the User's Guide was substantially rewritten to reflect the
modernized IPv6 stack, including documentation of the new Ipv6NetworkConfigurator
and the XML routing configuration format. New User's Guide chapters describe
satellite mobility and geographic visualization, and the BGP documentation
was extended with the configuration file format and the new IPv6 (MP-BGP)
support. NED documentation for many IPv6 and Mobile IPv6 modules was expanded
and brought up to date, and several example simulations (e.g. the PIM
examples) received README files.
15. Notable bug fixes and other changes
Most modules were migrated to the displayStringTextFormat mechanism for their
Qtenv display strings, replacing custom refreshDisplay() overrides; the old
WATCH_xxx() macros were replaced with the unified WATCH() macro, and additional
watches were added for computed values. This affects only the graphical runtime
and has no effect on results.
The LdpMplsRouter and RsvpMplsRouter modules were refactored to share a common
MplsRouterBase base, eliminating duplicated code. This changes the module
initialization order and therefore the random number draw order, so MPLS
simulation results may change.
Fixed two IPsec ESP correctness bugs: an incorrect block size unit in payload
padding, and an incorrect total length computation during decryption.
Fixed a UDP payload padding removal bug that could misdetect trailing data, and a
crash that occurred when combining multicast traffic with VLANs.
Fixed a memory leak in MessageDispatcher that occurred when packet delivery
failed.
Standardized many internal integer types in the SCTP model and across the
codebase, improving consistency.
A new STAGE_NETWORK_INTERFACE_CONFIGURATION stage was inserted into the
lifecycle start and stop operations, so that network interfaces are
configured before IPv6 addresses are assigned. This fixes network interfaces
not re-obtaining their global IPv6 address after a node restart.
Fixed L2NetworkConfigurator to configure all ports in the network instead of
just the first one, and added a dumpConfiguration parameter for debugging.
Fixed visualizers to subscribe to the signals of their subject module rather
than the visualization target module, so that the two can be fully decoupled.
The InfoVisualizer now supports the %N directive for displaying the display
name of a module.
Fixed crashes that occurred when running GPSR over IPv6.
IPv6 Neighbor Discovery packets are now created with descriptive names,
making logs and packet traces easier to read.
Removed several low-value or redundant IPv6 example simulations (demonetworketh,
ipv6bulk, and ipv6nclients).
Several additional issues reported on GitHub have also been fixed.
INET-4.6 (February 2026) — feature release
------------------------------------------
This is a new feature release in the INET 4.x branch. Highlights include new
protocol implementations for QUIC, Ethernet 10BASE-T1S, IPsec, and MRP; major
refinements to the clock model; a reimplementation of IEEE 802.1AS (gPTP); and
an important refactoring of the wireless physical layer's analog domain. The
release continues to focus on improving correctness, accuracy, modularity, and
long-term maintainability while addressing several long-standing limitations.
Requires OMNeT++ 6.2 or later.
For the full list of additions, removals, and changes (features, modules, packet
chunks/tags, signals, statistics, and C++ classes), see ChangeLog in the src
folder.
For further questions, detailed explanations, and guided exploration of INET
concepts and features, a dedicated AI-powered wiki is now available at
https://deepwiki.com/inet-framework/inet
Notable backward-incompatible changes include the following:
1. Clock model refinement
The clock and oscillator models were substantially reworked to improve
accuracy, correctness, and robustness. Clock time to simulation time mapping
and clock-interval to oscillator-tick conversions were rewritten for
mathematical correctness, with stricter consistency checks. Accuracy was
improved using precise arithmetic and new scaling utilities (e.g.,
NumberNear1 and SimTimeScale). The design anticipates future 128-bit
simulation time support.
The updated model now accumulates fractional oscillator compensation for more
accurate timing. The clock's nominal tick interval must be explicitly
configured, as it no longer defaults to the simulation time resolution. The
drifting oscillator model was extended with a configurable frequency
compensation factor, distinct from the clock's step-based compensation
mechanism.
The architecture was modularized to allow multiple clocks to share a single
physical oscillator via the clock's oscillatorModule parameter. SettableClock
now includes an underlying free-running clock submodule to support
simulations that mix synchronized and unsynchronized time. A clock servo
model was added, including the IClockServo module interface and the
StepClockServo module for implementation.
Clock event handling was also refined: overdue events are now processed
immediately, in clock-time order, and newly scheduled events are inserted at
the lower bound of the corresponding simulation-time interval, preserving
stable ordering. Clock time to simulation time conversion methods now accept
explicit lower-bound arguments to ensure robust tie-breaking between adjacent
ticks.
Clock and oscillator documentation was significantly expanded and formalized
to reflect the stricter semantics of the new implementation.
This change is backward incompatible in that clock-based simulations may
produce slightly different statistical results due to the improved
correctness and accuracy of the model.
2. IEEE 802.1AS (gPTP) protocol reimplementation
Large parts of the protocol were reimplemented using formal state machines
for both peer delay measurement and time synchronization. Standards
conformance was improved, including correct handling of grandmaster and
neighbor rate ratios. The peer delay and time synchronization processes now
maintain separate state for requester/responder and sender/receiver roles.
The new model introduces a dedicated clock servo submodule for updating local
time. Peer delay measurements now use an exponential moving average for
improved stability and are performed using the unsynchronized local clock to
avoid interference during active time synchronization.
For improved standards compliance, message timestamping now occurs at
transmission start and reception start rather than at completion. As a
result, simulations must use physical layer modules that emit explicit
start-of-transmission and start-of-reception signals, such as the
StreamingTransmitter and DestreamingReceiver modules.
Due to the high precision required for time synchronization, accurately
modeling a 1 ppm clock drift with a nominal 10 ns tick interval requires very
fine time granularity. gPTP simulations therefore typically require
femtosecond (fs) simulation time resolution, which can be enabled via the
simtime-resolution configuration option.
This change is backward incompatible in that simulations using gPTP may
produce slightly different statistical results due to the improved
correctness and accuracy of the model.
3. Ethernet module renames
Existing Ethernet MAC modules were renamed to use the MacPhy suffix (e.g.
EthernetMacPhy, EthernetCsmaMacPhy) to reflect that they combine MAC and PHY
functionality in a single module. This resolves naming conflicts introduced
by the new dedicated EthernetCsmaMac and EthernetCsmaPhy modules, which
provide a modern, state-machine-based implementation of the individual layers
and are primarily used by the new Ethernet 10BASE-T1S model.
These changes are backward incompatible for simulations that directly
reference the old module names.
4. Wireless physical layer refactoring
The wireless physical layer was significantly refactored to simplify how the
analog representation of radio signals is selected. Instead of using separate
module types, radio and medium modules now use a signalAnalogRepresentation
parameter (unitDisk, scalar, or dimensional) to control their behavior.
Responsibility for computing reception success was partially moved from
receiver modules to their analog model submodules. To reflect broader
applicability, much of the former UnitDisk-specific implementation was
replaced by generic components, resulting in modules such as GenericRadio,
GenericTransmitter, and GenericReceiver, while UnitDisk remains available as
an analog domain representation.
Specific wireless technologies, including IEEE 802.11, IEEE 802.15.4, and
APSK, were refactored to align with the new architecture and can now be used
with the unitDisk signal analog representation.
5. CRC, FCS, and Checksum
Frame Check Sequence (FCS) is now used consistently for link-layer protocols
(e.g. Ethernet, IEEE 802.11), replacing the generic CRC terminology.
Accordingly, crcMode parameters in MAC and radio modules were renamed to
fcsMode. In the TCP/IP stack, the term checksum is now used explicitly for
16-bit one’s-complement sums, and crcMode was renamed to checksumMode.
The underlying implementations were modernized as well. New algorithms
(CRC32C, CRC16-IBM, CRC16-CCITT) were added, generic and configurable CRC
utilities were introduced, and protocol-specific handling was improved—most
notably, SCTP now uses a dedicated CRC32C implementation. These changes
improve standards compliance, verification reliability, and flexibility while
preserving existing behavior by default.
Note that these changes are backward incompatible for simulations that
explicitly configure the old crcMode or fcsMode parameters.
Notable backward compatible changes are the following:
1. 10BASE-T1S Ethernet physical layer
A 10BASE-T1S Ethernet model was added, implementing Physical Layer Collision
Avoidance (PLCA) in accordance with IEEE 802.3cg. The PLCA Reconciliation
Sublayer provides deterministic access to the shared medium by assigning
transmit opportunities (TOs) to nodes in a round-robin manner, effectively
eliminating the collisions typical of CSMA/CD and enabling efficient
half-duplex communication.
Unlike traditional point-to-point Ethernet topologies, 10BASE-T1S supports a
multidrop bus (mixing segment) in which multiple nodes can be daisy-chained
on a single twisted pair without a switch. The model introduces new modules
such as EthernetCsmaMac, EthernetPlca, and EthernetCsmaPhy; users should use
EthernetPlcaNode for hosts, EthernetPlcaInterface for network interfaces, and
EthernetMultidropLink for connectivity.
Several example simulations were added to demonstrate the new functionality.
The 10BASE-T1S protocol implementation was contributed by a generous industry
partner.
2. QUIC transport protocol
An implementation of the QUIC transport protocol was added, designed to be
structurally modular, and suitable for performance and protocol-level
experimentation. It models connection-oriented QUIC over UDP with explicit
connection and socket management, supports the full handshake including 0-RTT
connection establishment, and provides stream-based data transfer with
configurable per-stream and connection-level flow control.
The model includes congestion control with selectable algorithms (e.g.
NewReno), loss detection and retransmission with correct handling of
ACK-eliciting and non-ACK-eliciting frames, and Path MTU Discovery with
optional DPLPMTUD and ICMP Packet Too Big processing. It ensures correct byte
ordering and in-order delivery, uses randomized initial destination
connection IDs with robust lifecycle management, and supports clean
connection teardown with explicit close handling and delayed destruction
after CONNECTION_CLOSE.
Validation simulations are integrated into the fingerprint and validation
test framework. Overall, the QUIC model provides a solid and extensible
foundation for simulating modern UDP-based transport protocols and for
comparing their behavior against TCP under controlled conditions.
The QUIC protocol implementation was contributed by Timo Völker.
3. IPsec protocol
The IPv4 model was extended with a comprehensive IPsec implementation to
support secure network communication. The model supports both Authentication
Header (AH) and Encapsulating Security Payload (ESP), with an emphasis on
standards compliance, including correct AH header lengths and proper
placement of ESP trailers within encrypted payloads.
The implementation supports UDP traffic and multicast communication, enabling
a wide range of secured network scenarios. It also includes protocol-specific
packet dissectors and packet printers to allow inspection and analysis of
protected traffic.
The IPsec protocol implementation was contributed by Marcel Marek.
4. Media Redundancy Protocol (MRP)
Media Redundancy Protocol (MRP) was added to provide high-availability
Ethernet ring redundancy. It improves network reliability by managing
redundant paths in ring topologies, preventing loops, and enabling fast
recovery after link failures.
The EthernetSwitch module now includes MRP components such as the core
protocol logic, redundancy-aware forwarding, a specialized MAC forwarding
table, and support for interconnecting multiple rings or redundant segments.
The implementation follows the relevant standards, using a specific multicast
MAC address for protocol communication and supporting all major MRP message
types for topology monitoring and change detection.
Additional signals and statistics were added to improve observability, and
the implementation was validated under extreme conditions (e.g. very high
packet error rates) to ensure robust recovery behavior.
The MRP protocol implementation was contributed by Daniel Zeitler
5. TCP auto-read mode
The TCP modules were extended with an explicit read mode to support proper
TCP flow control. Previously, all TCP sockets operated in auto-read mode,
where received data was immediately delivered to the application, effectively
disabling flow control.
When explicit read mode is enabled by setting autoRead to false in
TcpOpenCommand, applications must issue read requests, similar to real socket
read() calls. TCP then delivers buffered or newly arrived data up to a
specified byte limit, reducing the advertised window as data arrives and
increasing it again only when buffer space is freed by read requests.
Auto-read mode remains the default for backward compatibility and continues
to advertise the full configured window.
Read requests are represented by TcpReadCommand, and a new request may be
issued only after the previous one has been satisfied. In addition, delivery
of the TCP_I_PEER_CLOSED indication after a FIN is now delayed until all
buffered data has been read by the application.
6. AODV gateway
AODV has been extended to support routing toward external IP networks via a
statically configured gateway. By defining the new gatewayAddress parameter,
nodes can now handle traffic destined for external addresses by automatically
initiating route discovery for the specified gateway. Once the route to the
gateway is discovered, external packets are queued and forwarded accordingly.
A showcase was added demonstrating AODV support for routing traffic to
external networks via a statically configured gateway, featuring a wireless
ad hoc network communicating with a wired Ethernet host through a gateway
router.
7. GPSR multiple network interfaces
The GPSR (Greedy Perimeter Stateless Routing) protocol was updated to support
simultaneous use of multiple network interfaces, with refactored logic and
data structures to track neighbors on a per-interface basis. Beacons are now
sent on all configured interfaces, neighbor information stores both position
and interface ID, and packet forwarding correctly uses the interface