Кратко

  • Ревизия 15 проекта MASQUE создаёт эмулированный Ethernet-канал поверх HTTP, но не связывает аутентифицированного HTTP-пользователя с каждым заявленным исходным MAC.
  • 101 или 2xx подтверждает установление туннеля; режим, порядок, фильтр источника, VLAN, петли, выход и результат остаются отдельными фактами.

draft-ietf-masque-connect-ethernet-15 опубликован 30 сентября 2026 года. Это активный документ рабочей группы MASQUE с намерением Proposed Standard. Datatracker показывает IESG Evaluation и подстатус AD Followup; после ревизии 15 проверка IANA вернулась в состояние «Version Changed - Review Needed». Документ остаётся Internet-Draft, а не RFC; зафиксированные источники не доказывают внедрение, распространение, соответствие реализации, производительность или инцидент.

В HTTP/1.1 клиент отправляет GET и Upgrade: connect-ethernet, а успех обозначается 101 Switching Protocols. HTTP/2 и HTTP/3 применяют Extended CONNECT с :protocol = connect-ethernet; подходящий 2xx запускает Capsule Protocol. Успех означает готовность прокси пересылать Ethernet-кадры.

Кто вошёл и кем представился кадр

Туннель должен быть защищён TLS, QUIC-шифрованием или эквивалентом. Это аутентифицирует транспортное отношение. Но проект разрешает произвольные кадры, включая произвольный исходный MAC, и предупреждает об имитации хоста, отравлении ARP, NDP, CAM и отказе в обслуживании.

HTTP-принципал, исходный MAC и полномочие вызвать эффект в широковещательном домене — три утверждения. Context ID 0 лишь говорит, что полезная нагрузка является Ethernet-кадром. Она начинается с адреса назначения и заканчивается перед FCS; исходный FCS не переносится и создаётся заново на выходе. Целостность транспортировки не доказывает принадлежность адреса.

Проект допускает локальные меры: один MAC для point-to-site, настроенные списки, IEEE 802.1X, аутентификацию пользователей и ограничения скорости. Динамическое согласование MAC-фильтра оставлено будущим расширениям. Поэтому оператор обязан связать принципала, URI, допустимые MAC/VLAN/EtherType, срок и решение по конкретному кадру.

Посредник меняет свойства, а не название туннеля

HTTP Datagrams могут идти как QUIC DATAGRAM либо как DATAGRAM capsules по потоку. QUIC DATAGRAM не фрагментируется. Если Ethernet-кадр не помещается, сторона обязана отбросить его и не должна незаметно перейти на capsule.

Capsule способна перенести большой кадр через несколько TCP- или QUIC-пакетов. Однако гарантии порядка не универсальны. Посредник может принять capsule и перекодировать её в QUIC DATAGRAM. На панели остаётся один запрос и один туннель, но фактический режим после посредника влияет на максимальный размер, потерю и порядок.

Неизвестный Context ID или Datagram, пришедший раньше запроса, можно тихо отбросить либо кратко буферизовать. Буферы ограничиваются для защиты ресурсов. После декапсуляции кадр сверх лимита выходного интерфейса, сети или получателя тоже отбрасывается. Если доставка в нижележащий сегмент невозможна, кадр уничтожается.

Значит, наблюдаемость должна фиксировать режим на каждом участке, регистрацию Context, доступный размер, обнаруженную PMTU, перекодирование посредником, причину потери и выход. Непрерывность HTTP не является непрерывностью семантики доставки.

VLAN и мост не входят в квитанцию 200

Теги 802.1Q по умолчанию проходят прозрачно. Если вход или выход интерпретирует их, стороны нуждаются в сигнализированном либо ручном соглашении, которого проект не определяет. VLAN можно связать с отдельным URI, тег можно удалить и восстановить, но тогда таблица URI–VLAN становится политикой авторизации.

Подключение эмулированного линка к внешней сети добавляет функции моста: broadcast, multicast, PAUSE, обучение и предотвращение петель. Два правильных туннеля способны образовать неправильную петлю. STP/RSTP, делегирование ядру, доказуемо свободная от петель топология и лимиты широковещательного трафика — отдельные механизмы.

Свидетельство строится по пути кадра

Полезная цепочка содержит: HTTP-конечную точку; аутентификацию и версию политики; URI/VLAN; ответ установления; Context и режим до/после посредника; решение по MAC; обработку тега; состояние моста; размер и очередь; результат выхода; наблюдение назначения. Первая половина не подписывает вторую.

Тексты Heng Lu о Running-Code Primacy, минимальной начальной спецификации и проблеме агентности используются как раскрытая редакционная линза. Общая спецификация координирует узкий механизм, а работающие системы доказывают дополнительные полномочия и эффекты. Это аналитическое прочтение, не заявление о намерениях IETF.

Источники