Max Fragment Length extension
E258092
The Max Fragment Length extension is a Transport Layer Security (TLS) protocol feature that allows clients and servers to negotiate smaller-than-default record sizes to accommodate constrained environments or avoid IP fragmentation.
All labels observed (1)
| Label | Occurrences |
|---|---|
| Max Fragment Length extension canonical | 2 |
How this entity was disambiguated
This entity first appeared as the object of triple T2359741 — resolving that mention is where its identity was fixed. The disambiguator weighed these candidate entities and picked the highlighted one (or “None”, minting a new entity). This is how homonymy is resolved: the same surface form can point to different entities.
Target entity: Max Fragment Length extension Context triple: [RFC 3546, defines, Max Fragment Length extension]
-
A.
IEEE 802.1Qfz
IEEE 802.1Qfz is an Ethernet networking standard that defines enhancements for time-sensitive networking, focusing on improved traffic management and deterministic communication.
-
B.
RFC 6146
RFC 6146 is an IETF standard that specifies the behavior and requirements for NAT64, enabling IPv6-only clients to communicate with IPv4 servers through protocol translation.
-
C.
IEEE 802.1Qfj
IEEE 802.1Qfj is an amendment to the IEEE 802.1Q standard that defines enhancements for deterministic, time-sensitive networking in bridged and virtualized Ethernet networks.
-
D.
RFC 6145
RFC 6145 is an IETF standard that specifies the stateless translation mechanism between IPv4 and IPv6 packet headers used in NAT64 environments.
-
E.
IEEE 802.1Qfk
IEEE 802.1Qfk is an IEEE networking standard that defines mechanisms for enhanced VLAN and Ethernet bridging behavior within the broader IEEE 802.1 family.
- F. None of above. chosen
- G. Unsure - the case is ambiguous/there is not enough information to decide.
Target entity: Max Fragment Length extension Target entity description: The Max Fragment Length extension is a Transport Layer Security (TLS) protocol feature that allows clients and servers to negotiate smaller-than-default record sizes to accommodate constrained environments or avoid IP fragmentation.
-
A.
IEEE 802.1Qfz
IEEE 802.1Qfz is an Ethernet networking standard that defines enhancements for time-sensitive networking, focusing on improved traffic management and deterministic communication.
-
B.
RFC 6146
RFC 6146 is an IETF standard that specifies the behavior and requirements for NAT64, enabling IPv6-only clients to communicate with IPv4 servers through protocol translation.
-
C.
IEEE 802.1Qfj
IEEE 802.1Qfj is an amendment to the IEEE 802.1Q standard that defines enhancements for deterministic, time-sensitive networking in bridged and virtualized Ethernet networks.
-
D.
RFC 6145
RFC 6145 is an IETF standard that specifies the stateless translation mechanism between IPv4 and IPv6 packet headers used in NAT64 environments.
-
E.
IEEE 802.1Qfk
IEEE 802.1Qfk is an IEEE networking standard that defines mechanisms for enhanced VLAN and Ethernet bridging behavior within the broader IEEE 802.1 family.
- F. None of above. chosen
Statements (48)
| Predicate | Object |
|---|---|
| instanceOf |
TLS extension
ⓘ
Transport Layer Security feature ⓘ |
| abbreviation | MFL ⓘ |
| allowsMaxFragmentLength |
1024 bytes
ⓘ
2048 bytes ⓘ 4096 bytes ⓘ 512 bytes ⓘ |
| appliesTo |
TLS application data records
ⓘ
TLS handshake records ⓘ |
| benefit |
helps constrained embedded devices
ⓘ
helps devices with small MTUs ⓘ reduces memory requirements for record buffers ⓘ reduces risk of IP-layer fragmentation ⓘ |
| category | TLS performance and transport optimization ⓘ |
| defaultRecordSizeWithoutExtension |
16384 bytes
ⓘ
2^14 bytes ⓘ |
| definedBy | Internet Engineering Task Force ⓘ |
| definedIn | RFC 6066 ⓘ |
| doesNotAffect | TLS alert record size semantics ⓘ |
| extensionTypeCode | 1 ⓘ |
| IANAExtensionType | max_fragment_length ⓘ |
| introducedYear | 2011 ⓘ |
| negotiates | maximum TLS record payload size ⓘ |
| negotiationDirection | client to server ⓘ |
| negotiationOutcome | applies for the duration of the TLS session ⓘ |
| notApplicableTo |
RFC 8446
ⓘ
surface form:
TLS 1.3
|
| partOfProtocol |
TLS 1.0
ⓘ
TLS 1.1 ⓘ TLS 1.2 ⓘ TLS ⓘ
surface form:
Transport Layer Security
|
| purpose |
to accommodate constrained environments
ⓘ
to avoid IP fragmentation ⓘ to negotiate smaller-than-default TLS record sizes ⓘ |
| relatedTo |
IP fragmentation
ⓘ
TLS ⓘ
surface form:
TLS record layer
path MTU ⓘ |
| requires | support by both TLS client and TLS server ⓘ |
| RFCNumber | 6066 ⓘ |
| scope | per TLS session ⓘ |
| sectionOfRFC |
RFC 6066
ⓘ
surface form:
RFC 6066 Section 4
|
| securityConsideration |
may increase observability of traffic patterns due to more records
ⓘ
smaller records increase per-record overhead ⓘ |
| selectionRule |
server must not select a larger fragment length than offered by client
ⓘ
server must not select a value not offered by client ⓘ |
| standardTrack |
IETF Internet standards process
ⓘ
surface form:
IETF Standards Track
|
| status | standardized ⓘ |
| usedIn |
TLS ClientHello
ⓘ
ServerHello with extensions ⓘ
surface form:
TLS ServerHello
|
How these facts were elicited
The pipeline generated the facts above by prompting gpt-5.1 with this entity's name + description and the instruction below.
You are a knowledge base construction expert. Given a subject entity and a description of it, return factual statements that you know for the subject as a JSON list of dictionaries(triples), where keys must be "subject", "predicate" and "object". The number of facts may be very high, between 25 to 50 or more, for very popular subjects. For less popular subjects, the number of facts can be very low, like 5 or 10. # Requirements - If you don't know the subject at all, return an empty list. - If the subject is not a named entity, return an empty list. - Include at least one triple where predicate is "instanceOf". - Do not get too wordy. - Separate several objects into multiple triples with one object.
Subject: Max Fragment Length extension Description of subject: The Max Fragment Length extension is a Transport Layer Security (TLS) protocol feature that allows clients and servers to negotiate smaller-than-default record sizes to accommodate constrained environments or avoid IP fragmentation.
Referenced by (2)
Full triples — surface form annotated when it differs from this entity's canonical label.