{
    "api_version": "1",
    "kind": "dse_post",
    "self": "https://update.dsesecurity.com/api/v1/posts/map-each-six-bit-dscp-to-a-configured-per-hop-behavior/",
    "item": {
        "id": "https://update.dsesecurity.com/updates/map-each-six-bit-dscp-to-a-configured-per-hop-behavior/",
        "slug": "map-each-six-bit-dscp-to-a-configured-per-hop-behavior",
        "url": "https://update.dsesecurity.com/updates/map-each-six-bit-dscp-to-a-configured-per-hop-behavior/",
        "alternate_urls": {
            "markdown": "https://update.dsesecurity.com/updates/map-each-six-bit-dscp-to-a-configured-per-hop-behavior.md",
            "json": "https://update.dsesecurity.com/api/v1/posts/map-each-six-bit-dscp-to-a-configured-per-hop-behavior/"
        },
        "title": "Map each six-bit DSCP to a configured per-hop behavior",
        "summary": "Use RFC 2474 — Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers to review this narrow operational decision without extending the source beyond its stated scope.",
        "format": {
            "slug": "checklist",
            "name": "Checklist"
        },
        "priority": {
            "slug": "advisory",
            "name": "Advisory"
        },
        "featured": false,
        "image": {
            "theme": "network-infrastructure",
            "label": "Networks & infrastructure",
            "alt": "Resilient network core with engineered blue and gold data paths.",
            "card_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-card.webp?v=1.8.20",
            "hero_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-hero.webp?v=1.8.20",
            "social_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20",
            "width": 2400,
            "height": 1350
        },
        "topics": [
            {
                "slug": "it",
                "name": "IT",
                "url": "https://update.dsesecurity.com/topic/it/"
            },
            {
                "slug": "networks-infrastructure",
                "name": "Networks & Infrastructure",
                "url": "https://update.dsesecurity.com/topic/networks-infrastructure/"
            }
        ],
        "author": {
            "name": "DSE Security Editorial Team",
            "url": "https://update.dsesecurity.com/#editorial-team",
            "type": "Organization"
        },
        "publisher": {
            "name": "Detection Systems & Engineering",
            "url": "https://dsesecurity.com/"
        },
        "published_at": "2026-08-27T12:16:24+00:00",
        "modified_at": "2026-08-27T12:53:57+00:00",
        "reviewed_on": "2026-08-26",
        "reading_minutes": 3,
        "word_count": 613,
        "potentially_affected": "Teams, systems, services, or facilities within the stated scope of RFC 2474 — Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers",
        "dse_recommendation": "Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards.",
        "primary_source": {
            "name": "RFC 2474 — Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers",
            "url": "https://www.rfc-editor.org/rfc/rfc2474.html",
            "published_on": null,
            "authority": "www.rfc-editor.org"
        },
        "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/",
        "usage_info": "https://update.dsesecurity.com/usage/",
        "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.",
        "content_html": "<p>Treat this document as a focused evidence review: Map each six-bit DSCP to a configured per-hop behavior. Only the official source and traced locations below supply facts. Confirm applicability before acting.</p>\n<h2>Source fact:</h2>\n<p>The official <a href=\"https://www.rfc-editor.org/rfc/rfc2474.html\" target=\"_blank\" rel=\"noopener noreferrer\">RFC 2474 — Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers</a> from RFC Editor / Internet Engineering Task Force supports the following bounded statements:</p>\n<ul>\n<li>The DS field uses a six-bit DSCP to select per-hop behavior; the remaining two bits are excluded from that selection. The research record locates this support at <strong>Section 3 (Differentiated Services Field Definition)</strong>.</li>\n<li>A compliant node must match the entire six-bit DSCP and support a configurable mapping from codepoints to per-hop behaviors. The research record locates this support at <strong>Section 3 (Differentiated Services Field Definition), codepoint mapping</strong>.</li>\n<li>An unrecognized codepoint should receive the Default behavior without being rewritten and must not cause the node to malfunction. The research record locates this support at <strong>Section 3 (Differentiated Services Field Definition), unrecognized codepoints</strong>.</li>\n</ul>\n<p>These statements are the factual basis for this document. Do not extend them into a broader assurance. Review address plans, interfaces, routes, peers, protocol roles, timers, middleboxes, and intended failure domains only where the source and recorded environment align.</p>\n<h2>What the source does not establish</h2>\n<p>This RFC evidence supports only the named network-protocol decision; it does not select vendor settings, topology, capacity, or an acceptable failure mode. A correct source interpretation can still be inapplicable to a particular design. Confirm DNS, Active Directory authentication, PKI, time, routing policy, transport reachability, and monitoring, ownership, and change authority instead of treating documented behavior as a deployment guarantee.</p>\n<h2>Applicability questions</h2>\n<ul>\n<li>For source statement 1 at <strong>Section 3 (Differentiated Services Field Definition)</strong>, which observable configuration, record, or test can confirm applicability here?</li>\n<li>For source statement 2 at <strong>Section 3 (Differentiated Services Field Definition), codepoint mapping</strong>, which observable configuration, record, or test can confirm applicability here?</li>\n<li>For source statement 3 at <strong>Section 3 (Differentiated Services Field Definition), unrecognized codepoints</strong>, which observable configuration, record, or test can confirm applicability here?</li>\n<li>Within address plans, interfaces, routes, peers, protocol roles, timers, middleboxes, and intended failure domains, which versions, roles, and configuration states define the review population?</li>\n<li>Could DNS, Active Directory authentication, PKI, time, routing policy, transport reachability, and monitoring invalidate the test, hide a failure, or change applicability?</li>\n<li>Who owns the decision, and which observation requires stopping, escalation, or rollback?</li>\n</ul>\n<h2>DSE recommendation:</h2>\n<p>DSE recommends using the cited source as the evidence anchor for this decision. Start with applicability, then compare the observed state with the cited source. Record the source location, examined part of address plans, interfaces, routes, peers, protocol roles, timers, middleboxes, and intended failure domains, observed and expected states, owner, and reason for deviation.</p>\n<p>For an approved change, define prerequisites, a limited test path, success and stop conditions, monitoring, and rollback. Check DNS, Active Directory authentication, PKI, time, routing policy, transport reachability, and monitoring in design order. Protect credentials, keys, recovery material, personal data, and sensitive topology in evidence.</p>\n<h2>Verification and evidence</h2>\n<p>Evidence should let another reviewer reproduce this decision. Retain observations beside the traced locations <strong>Section 3 (Differentiated Services Field Definition)</strong>; <strong>Section 3 (Differentiated Services Field Definition), codepoint mapping</strong>; <strong>Section 3 (Differentiated Services Field Definition), unrecognized codepoints</strong>. Favor configuration snapshots, route or neighbor state, packet captures, counters, topology records, and controlled failover results, linked to stable identifiers, time, and operator.</p>\n<p>Keep before-state evidence, approval, test or change result, exceptions, and after-state evidence together. Use an approved lab, window, or nonproduction path for risky tests. Set a recheck trigger for version, architecture, dependency, vendor, incident, or ownership change. A check proves only what was observed.</p>\n<h2>Official references</h2>\n<ul>\n<li><a href=\"https://www.rfc-editor.org/rfc/rfc2474.html\" target=\"_blank\" rel=\"noopener noreferrer\">RFC 2474 — Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers</a> — RFC Editor / Internet Engineering Task Force</li>\n</ul>",
        "content_text": "Treat this document as a focused evidence review: Map each six-bit DSCP to a configured per-hop behavior. Only the official source and traced locations below supply facts. Confirm applicability before acting.\nSource fact:\nThe official RFC 2474 — Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers from RFC Editor / Internet Engineering Task Force supports the following bounded statements:\n\nThe DS field uses a six-bit DSCP to select per-hop behavior; the remaining two bits are excluded from that selection. The research record locates this support at Section 3 (Differentiated Services Field Definition).\nA compliant node must match the entire six-bit DSCP and support a configurable mapping from codepoints to per-hop behaviors. The research record locates this support at Section 3 (Differentiated Services Field Definition), codepoint mapping.\nAn unrecognized codepoint should receive the Default behavior without being rewritten and must not cause the node to malfunction. The research record locates this support at Section 3 (Differentiated Services Field Definition), unrecognized codepoints.\n\nThese statements are the factual basis for this document. Do not extend them into a broader assurance. Review address plans, interfaces, routes, peers, protocol roles, timers, middleboxes, and intended failure domains only where the source and recorded environment align.\nWhat the source does not establish\nThis RFC evidence supports only the named network-protocol decision; it does not select vendor settings, topology, capacity, or an acceptable failure mode. A correct source interpretation can still be inapplicable to a particular design. Confirm DNS, Active Directory authentication, PKI, time, routing policy, transport reachability, and monitoring, ownership, and change authority instead of treating documented behavior as a deployment guarantee.\nApplicability questions\n\nFor source statement 1 at Section 3 (Differentiated Services Field Definition), which observable configuration, record, or test can confirm applicability here?\nFor source statement 2 at Section 3 (Differentiated Services Field Definition), codepoint mapping, which observable configuration, record, or test can confirm applicability here?\nFor source statement 3 at Section 3 (Differentiated Services Field Definition), unrecognized codepoints, which observable configuration, record, or test can confirm applicability here?\nWithin address plans, interfaces, routes, peers, protocol roles, timers, middleboxes, and intended failure domains, which versions, roles, and configuration states define the review population?\nCould DNS, Active Directory authentication, PKI, time, routing policy, transport reachability, and monitoring invalidate the test, hide a failure, or change applicability?\nWho owns the decision, and which observation requires stopping, escalation, or rollback?\n\nDSE recommendation:\nDSE recommends using the cited source as the evidence anchor for this decision. Start with applicability, then compare the observed state with the cited source. Record the source location, examined part of address plans, interfaces, routes, peers, protocol roles, timers, middleboxes, and intended failure domains, observed and expected states, owner, and reason for deviation.\nFor an approved change, define prerequisites, a limited test path, success and stop conditions, monitoring, and rollback. Check DNS, Active Directory authentication, PKI, time, routing policy, transport reachability, and monitoring in design order. Protect credentials, keys, recovery material, personal data, and sensitive topology in evidence.\nVerification and evidence\nEvidence should let another reviewer reproduce this decision. Retain observations beside the traced locations Section 3 (Differentiated Services Field Definition); Section 3 (Differentiated Services Field Definition), codepoint mapping; Section 3 (Differentiated Services Field Definition), unrecognized codepoints. Favor configuration snapshots, route or neighbor state, packet captures, counters, topology records, and controlled failover results, linked to stable identifiers, time, and operator.\nKeep before-state evidence, approval, test or change result, exceptions, and after-state evidence together. Use an approved lab, window, or nonproduction path for risky tests. Set a recheck trigger for version, architecture, dependency, vendor, incident, or ownership change. A check proves only what was observed.\nOfficial references\n\nRFC 2474 — Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers — RFC Editor / Internet Engineering Task Force",
        "content_markdown": "Treat this document as a focused evidence review: Map each six-bit DSCP to a configured per-hop behavior. Only the official source and traced locations below supply facts. Confirm applicability before acting.\n\n## Source fact:\n\nThe official [RFC 2474 — Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers](https://www.rfc-editor.org/rfc/rfc2474.html) from RFC Editor / Internet Engineering Task Force supports the following bounded statements:\n\n- The DS field uses a six-bit DSCP to select per-hop behavior; the remaining two bits are excluded from that selection. The research record locates this support at Section 3 (Differentiated Services Field Definition).\n\n- A compliant node must match the entire six-bit DSCP and support a configurable mapping from codepoints to per-hop behaviors. The research record locates this support at Section 3 (Differentiated Services Field Definition), codepoint mapping.\n\n- An unrecognized codepoint should receive the Default behavior without being rewritten and must not cause the node to malfunction. The research record locates this support at Section 3 (Differentiated Services Field Definition), unrecognized codepoints.\n\nThese statements are the factual basis for this document. Do not extend them into a broader assurance. Review address plans, interfaces, routes, peers, protocol roles, timers, middleboxes, and intended failure domains only where the source and recorded environment align.\n\n## What the source does not establish\n\nThis RFC evidence supports only the named network-protocol decision; it does not select vendor settings, topology, capacity, or an acceptable failure mode. A correct source interpretation can still be inapplicable to a particular design. Confirm DNS, Active Directory authentication, PKI, time, routing policy, transport reachability, and monitoring, ownership, and change authority instead of treating documented behavior as a deployment guarantee.\n\n## Applicability questions\n\n- For source statement 1 at Section 3 (Differentiated Services Field Definition), which observable configuration, record, or test can confirm applicability here?\n\n- For source statement 2 at Section 3 (Differentiated Services Field Definition), codepoint mapping, which observable configuration, record, or test can confirm applicability here?\n\n- For source statement 3 at Section 3 (Differentiated Services Field Definition), unrecognized codepoints, which observable configuration, record, or test can confirm applicability here?\n\n- Within address plans, interfaces, routes, peers, protocol roles, timers, middleboxes, and intended failure domains, which versions, roles, and configuration states define the review population?\n\n- Could DNS, Active Directory authentication, PKI, time, routing policy, transport reachability, and monitoring invalidate the test, hide a failure, or change applicability?\n\n- Who owns the decision, and which observation requires stopping, escalation, or rollback?\n\n## DSE recommendation:\n\nDSE recommends using the cited source as the evidence anchor for this decision. Start with applicability, then compare the observed state with the cited source. Record the source location, examined part of address plans, interfaces, routes, peers, protocol roles, timers, middleboxes, and intended failure domains, observed and expected states, owner, and reason for deviation.\n\nFor an approved change, define prerequisites, a limited test path, success and stop conditions, monitoring, and rollback. Check DNS, Active Directory authentication, PKI, time, routing policy, transport reachability, and monitoring in design order. Protect credentials, keys, recovery material, personal data, and sensitive topology in evidence.\n\n## Verification and evidence\n\nEvidence should let another reviewer reproduce this decision. Retain observations beside the traced locations Section 3 (Differentiated Services Field Definition); Section 3 (Differentiated Services Field Definition), codepoint mapping; Section 3 (Differentiated Services Field Definition), unrecognized codepoints. Favor configuration snapshots, route or neighbor state, packet captures, counters, topology records, and controlled failover results, linked to stable identifiers, time, and operator.\n\nKeep before-state evidence, approval, test or change result, exceptions, and after-state evidence together. Use an approved lab, window, or nonproduction path for risky tests. Set a recheck trigger for version, architecture, dependency, vendor, incident, or ownership change. A check proves only what was observed.\n\n## Official references\n\n- [RFC 2474 — Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers](https://www.rfc-editor.org/rfc/rfc2474.html) — RFC Editor / Internet Engineering Task Force"
    },
    "json_ld": {
        "@context": "https://schema.org",
        "@graph": [
            {
                "@type": "Organization",
                "@id": "https://dsesecurity.com/#organization",
                "name": "Detection Systems & Engineering",
                "alternateName": "DSE Security",
                "url": "https://dsesecurity.com/",
                "logo": {
                    "@type": "ImageObject",
                    "url": "https://update.dsesecurity.com/assets/dse-logo-20260812.png?v=1.8.20"
                }
            },
            {
                "@type": "Organization",
                "@id": "https://update.dsesecurity.com/#editorial-team",
                "name": "DSE Security Editorial Team",
                "url": "https://update.dsesecurity.com/",
                "parentOrganization": {
                    "@id": "https://dsesecurity.com/#organization"
                }
            },
            {
                "@type": "WebSite",
                "@id": "https://update.dsesecurity.com/#website",
                "name": "DSE Updates",
                "alternateName": "DSE Security Knowledge Hub",
                "url": "https://update.dsesecurity.com/",
                "inLanguage": "en-US",
                "publisher": {
                    "@id": "https://dsesecurity.com/#organization"
                },
                "potentialAction": {
                    "@type": "SearchAction",
                    "target": {
                        "@type": "EntryPoint",
                        "urlTemplate": "https://update.dsesecurity.com/?q={search_term_string}"
                    },
                    "query-input": "required name=search_term_string"
                }
            },
            {
                "@type": "WebPage",
                "@id": "https://update.dsesecurity.com/updates/map-each-six-bit-dscp-to-a-configured-per-hop-behavior/",
                "url": "https://update.dsesecurity.com/updates/map-each-six-bit-dscp-to-a-configured-per-hop-behavior/",
                "isPartOf": {
                    "@id": "https://update.dsesecurity.com/#website"
                },
                "lastReviewed": "2026-08-26"
            },
            {
                "@type": "BreadcrumbList",
                "@id": "https://update.dsesecurity.com/updates/map-each-six-bit-dscp-to-a-configured-per-hop-behavior/#breadcrumbs",
                "itemListElement": [
                    {
                        "@type": "ListItem",
                        "position": 1,
                        "name": "DSE Updates",
                        "item": "https://update.dsesecurity.com/"
                    },
                    {
                        "@type": "ListItem",
                        "position": 2,
                        "name": "Map each six-bit DSCP to a configured per-hop behavior",
                        "item": "https://update.dsesecurity.com/updates/map-each-six-bit-dscp-to-a-configured-per-hop-behavior/"
                    }
                ]
            },
            {
                "@type": [
                    "Article",
                    "TechArticle"
                ],
                "@id": "https://update.dsesecurity.com/updates/map-each-six-bit-dscp-to-a-configured-per-hop-behavior/#article",
                "identifier": "https://update.dsesecurity.com/updates/map-each-six-bit-dscp-to-a-configured-per-hop-behavior/",
                "url": "https://update.dsesecurity.com/updates/map-each-six-bit-dscp-to-a-configured-per-hop-behavior/",
                "headline": "Map each six-bit DSCP to a configured per-hop behavior",
                "description": "Use RFC 2474 — Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers to review this narrow operational decision…",
                "abstract": "Use RFC 2474 — Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers to review this narrow operational decision without extending the source beyond its stated scope.",
                "articleBody": "Treat this document as a focused evidence review: Map each six-bit DSCP to a configured per-hop behavior. Only the official source and traced locations below supply facts. Confirm applicability before acting.\nSource fact:\nThe official RFC 2474 — Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers from RFC Editor / Internet Engineering Task Force supports the following bounded statements:\n\nThe DS field uses a six-bit DSCP to select per-hop behavior; the remaining two bits are excluded from that selection. The research record locates this support at Section 3 (Differentiated Services Field Definition).\nA compliant node must match the entire six-bit DSCP and support a configurable mapping from codepoints to per-hop behaviors. The research record locates this support at Section 3 (Differentiated Services Field Definition), codepoint mapping.\nAn unrecognized codepoint should receive the Default behavior without being rewritten and must not cause the node to malfunction. The research record locates this support at Section 3 (Differentiated Services Field Definition), unrecognized codepoints.\n\nThese statements are the factual basis for this document. Do not extend them into a broader assurance. Review address plans, interfaces, routes, peers, protocol roles, timers, middleboxes, and intended failure domains only where the source and recorded environment align.\nWhat the source does not establish\nThis RFC evidence supports only the named network-protocol decision; it does not select vendor settings, topology, capacity, or an acceptable failure mode. A correct source interpretation can still be inapplicable to a particular design. Confirm DNS, Active Directory authentication, PKI, time, routing policy, transport reachability, and monitoring, ownership, and change authority instead of treating documented behavior as a deployment guarantee.\nApplicability questions\n\nFor source statement 1 at Section 3 (Differentiated Services Field Definition), which observable configuration, record, or test can confirm applicability here?\nFor source statement 2 at Section 3 (Differentiated Services Field Definition), codepoint mapping, which observable configuration, record, or test can confirm applicability here?\nFor source statement 3 at Section 3 (Differentiated Services Field Definition), unrecognized codepoints, which observable configuration, record, or test can confirm applicability here?\nWithin address plans, interfaces, routes, peers, protocol roles, timers, middleboxes, and intended failure domains, which versions, roles, and configuration states define the review population?\nCould DNS, Active Directory authentication, PKI, time, routing policy, transport reachability, and monitoring invalidate the test, hide a failure, or change applicability?\nWho owns the decision, and which observation requires stopping, escalation, or rollback?\n\nDSE recommendation:\nDSE recommends using the cited source as the evidence anchor for this decision. Start with applicability, then compare the observed state with the cited source. Record the source location, examined part of address plans, interfaces, routes, peers, protocol roles, timers, middleboxes, and intended failure domains, observed and expected states, owner, and reason for deviation.\nFor an approved change, define prerequisites, a limited test path, success and stop conditions, monitoring, and rollback. Check DNS, Active Directory authentication, PKI, time, routing policy, transport reachability, and monitoring in design order. Protect credentials, keys, recovery material, personal data, and sensitive topology in evidence.\nVerification and evidence\nEvidence should let another reviewer reproduce this decision. Retain observations beside the traced locations Section 3 (Differentiated Services Field Definition); Section 3 (Differentiated Services Field Definition), codepoint mapping; Section 3 (Differentiated Services Field Definition), unrecognized codepoints. Favor configuration snapshots, route or neighbor state, packet captures, counters, topology records, and controlled failover results, linked to stable identifiers, time, and operator.\nKeep before-state evidence, approval, test or change result, exceptions, and after-state evidence together. Use an approved lab, window, or nonproduction path for risky tests. Set a recheck trigger for version, architecture, dependency, vendor, incident, or ownership change. A check proves only what was observed.\nOfficial references\n\nRFC 2474 — Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers — RFC Editor / Internet Engineering Task Force",
                "datePublished": "2026-08-27T12:16:24+00:00",
                "dateModified": "2026-08-27T12:53:57+00:00",
                "mainEntityOfPage": {
                    "@id": "https://update.dsesecurity.com/updates/map-each-six-bit-dscp-to-a-configured-per-hop-behavior/"
                },
                "inLanguage": "en-US",
                "isAccessibleForFree": true,
                "author": {
                    "@type": "Organization",
                    "name": "DSE Security Editorial Team",
                    "url": "https://update.dsesecurity.com/#editorial-team"
                },
                "publisher": {
                    "@id": "https://dsesecurity.com/#organization"
                },
                "image": {
                    "@type": "ImageObject",
                    "@id": "https://update.dsesecurity.com/updates/map-each-six-bit-dscp-to-a-configured-per-hop-behavior/#primaryimage",
                    "url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20",
                    "contentUrl": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20",
                    "width": 1200,
                    "height": 630,
                    "caption": "Map each six-bit DSCP to a configured per-hop behavior"
                },
                "articleSection": [
                    "IT",
                    "Networks & Infrastructure"
                ],
                "keywords": [
                    "IT",
                    "Networks & Infrastructure",
                    "Checklist",
                    "Advisory priority"
                ],
                "genre": "Checklist",
                "about": [
                    {
                        "@type": "Thing",
                        "name": "IT",
                        "url": "https://update.dsesecurity.com/topic/it/"
                    },
                    {
                        "@type": "Thing",
                        "name": "Networks & Infrastructure",
                        "url": "https://update.dsesecurity.com/topic/networks-infrastructure/"
                    }
                ],
                "wordCount": 613,
                "timeRequired": "PT3M",
                "publishingPrinciples": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/",
                "usageInfo": "https://update.dsesecurity.com/usage/",
                "copyrightHolder": {
                    "@id": "https://dsesecurity.com/#organization"
                },
                "copyrightNotice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.",
                "citation": {
                    "@type": "CreativeWork",
                    "name": "RFC 2474 — Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers",
                    "url": "https://www.rfc-editor.org/rfc/rfc2474.html"
                }
            }
        ]
    }
}