⌕ Поиск по атласу

IETF · RFC · RFC6040

RFC6040 · Tunnelling of Explicit Congestion Notification

Tunnelling of Explicit Congestion Notification

This document redefines how the explicit congestion notification (ECN) field of the IP header should be constructed on entry to and exit from any IP-in-IP tunnel. On encapsulation, it updates RFC 3168 to bring all IP-in-IP tunnels (v4 or v6) into line with RFC 4301 IPsec ECN processing. On decapsulation, it updates both RFC 3168 and RFC 4301 to add new behaviours for previously unused combinations of inner and outer headers. The new rules ensure the ECN field is correctly propagated across a tunnel whether it is used to signal one or two severity levels of congestion; whereas before, only one severity level was supported. Tunnel endpoints can be updated in any order without affecting pre-existing uses of the ECN field, thus ensuring backward compatibility. Nonetheless, operators wanting to support two severity levels (e.g., for pre-congestion notification -- PCN) can require compliance with this new specification. A thorough analysis of the reasoning for these changes and the implications is included. In the unlikely event that the new rules do not meet a specific need, RFC 4774 gives guidance on designing alternate ECN semantics, and this document extends that to include tunnelling issues. [STANDARDS-TRACK]

Официальная английская аннотация

This document redefines how the explicit congestion notification (ECN) field of the IP header should be constructed on entry to and exit from any IP-in-IP tunnel. On encapsulation, it updates RFC 3168 to bring all IP-in-IP tunnels (v4 or v6) into line with RFC 4301 IPsec ECN processing. On decapsulation, it updates both RFC 3168 and RFC 4301 to add new behaviours for previously unused combinations of inner and outer headers. The new rules ensure the ECN field is correctly propagated across a tunnel whether it is used to signal one or two severity levels of congestion; whereas before, only one severity level was supported. Tunnel endpoints can be updated in any order without affecting pre-existing uses of the ECN field, thus ensuring backward compatibility. Nonetheless, operators wanting to support two severity levels (e.g., for pre-congestion notification -- PCN) can require compliance with this new specification. A thorough analysis of the reasoning for these changes and the implications is included. In the unlikely event that the new rules do not meet a specific need, RFC 4774 gives guidance on designing alternate ECN semantics, and this document extends that to include tunnelling issues. [STANDARDS-TRACK]

Связи документа

updates: RFC3168, RFC4301, RFC4774

updated_by: RFC9601

Официальный источник · 2010-11-01

Полные импортированные сведения карточки
{
  "id": "RFC6040",
  "number": 6040,
  "title_en": "Tunnelling of Explicit Congestion Notification",
  "title_ru": "",
  "summary_ru": "",
  "purpose_ru": "",
  "use_ru": "",
  "full_translation_path": "",
  "full_translation_checked_at": "",
  "full_translation_source_sha256": "",
  "architect_note_ru": "",
  "topics_ru": [],
  "translation_state": "not_prepared",
  "verification_level": "not_prepared",
  "verification_level_ru": "Русская выжимка не подготовлена",
  "verification_note_ru": "",
  "abstract_en": "This document redefines how the explicit congestion notification (ECN) field of the IP header should be constructed on entry to and exit from any IP-in-IP tunnel. On encapsulation, it updates RFC 3168 to bring all IP-in-IP tunnels (v4 or v6) into line with RFC 4301 IPsec ECN processing. On decapsulation, it updates both RFC 3168 and RFC 4301 to add new behaviours for previously unused combinations of inner and outer headers. The new rules ensure the ECN field is correctly propagated across a tunnel whether it is used to signal one or two severity levels of congestion; whereas before, only one severity level was supported. Tunnel endpoints can be updated in any order without affecting pre-existing uses of the ECN field, thus ensuring backward compatibility. Nonetheless, operators wanting to support two severity levels (e.g., for pre-congestion notification -- PCN) can require compliance with this new specification. A thorough analysis of the reasoning for these changes and the implications is included. In the unlikely event that the new rules do not meet a specific need, RFC 4774 gives guidance on designing alternate ECN semantics, and this document extends that to include tunnelling issues. [STANDARDS-TRACK]",
  "authors": [
    "B. Briscoe"
  ],
  "organizations": [],
  "publication_date": "2010-11-01",
  "current_status": "PROPOSED STANDARD",
  "current_status_ru": "Предлагаемый стандарт",
  "publication_status": "PROPOSED STANDARD",
  "publication_status_ru": "Предлагаемый стандарт",
  "lifecycle": "active",
  "lifecycle_ru": "Действующий",
  "stream": "IETF",
  "stream_ru": "IETF",
  "area": "wit",
  "area_ru": "Веб и транспорт Интернета",
  "working_group": "tsvwg",
  "source_draft": "draft-ietf-tsvwg-ecn-tunnel-10",
  "page_count": 35,
  "doi": "10.17487/RFC6040",
  "keywords": [
    "Congestion Control and Management",
    "Congestion Notification",
    "Information Security",
    "Tunnelling",
    "Encapsulation",
    "Decapsulation",
    "Protocol",
    "ECN",
    "IPsec"
  ],
  "formats": [
    "TXT",
    "HTML"
  ],
  "relations": {
    "obsoletes": [],
    "obsoleted_by": [],
    "updates": [
      "RFC3168",
      "RFC4301",
      "RFC4774"
    ],
    "updated_by": [
      "RFC9601"
    ],
    "is_also": [],
    "see_also": []
  },
  "links": {
    "info": "https://www.rfc-editor.org/info/rfc6040/",
    "html": "https://www.rfc-editor.org/rfc/rfc6040.html",
    "txt": "https://www.rfc-editor.org/rfc/rfc6040.txt",
    "datatracker": "https://datatracker.ietf.org/doc/rfc6040/"
  }
}