주요 분야
인터넷 인프라
‘주요 분야’ 패싯에서 인터넷 인프라 인텔리전스는 보고 내용을 주 영역별로 묶어, 독자가 인터넷 인프라, 거버넌스, 연결성 시장 또는 디지털 자본 가운데 특정 영역을 집중적으로 따라갈 수 있도록 합니다. 이 페이지는 별도 카테고리 페이지에 나뉘어 있을 수 있는 관련 기사, 공개 증거, 기관, 기업, 인물, 지역적 노출, 운영 의존성, 시장 맥락을 한데 모읍니다. 아울러 해당 영역, 예상 행위자 유형, 시장 또는 거버넌스 맥락, 그리고 신호를 비교할 때 독자가 활용해야 할 출처 자료를 설명합니다. 운영자, 분석가, 거버넌스 분야 독자는 같은 영역이 이벤트, 프로필, 시장 변화, 공개 출처 증거, 지역 의존성, 보다 장기적인 주기의 인프라 의사결정 전반에서 시간에 따라 어떻게 나타나는지 살펴볼 수 있습니다.
역사
이더넷 프레임은 IP 네트워크를 건넜다. LAN은 함께 오지 않았다: RFC 3378
멀리 떨어진 두 이더넷 구간이 익숙한 하나의 프레임을 주고받을 수 있었지만, 터널은 그들의 지역적 가정을 거리에서도 참이 되게 하지 않았다.
역사
미지원 속성 하나가 전체 작업 변경을 무효화할 수 있었다: RFC 3380
프린터는 편집 전체를 거부할 수 있었습니다. 2002년 RFC 3380은 다중 속성 변경을 하나의 결정으로 만들었습니다. 유효한 결과 작업 상태를 수용하거나, 아니면 기존 작업을 그대로 두는 방식입니다.
역사
레지스트라는 도메인을 관리할 수 있었다. 그러나 네임스페이스를 지배한 것은 레지스트리였다: RFC 3375
고객은 카운터에서 한 회사를 봤지만, 지속적인 권한은 그 뒤편의 다른 시스템에 있었다.
역사
이름 없이 레코드를 가리킬 수 있었던 링크: RFC 3368
RFC 3368은 일반 이름을 링크로 옮겨 보내려 했습니다. 두 가지 URI 형식은 조용히 서비스 선택 문제를 서로 다른 곳에 배치했습니다. 주소가 하나의 리졸버를 고를 수도, 선택을 클라이언트에 남길 수도 있었습니다.
역사
하나의 통화에는 두 개의 진실이 있었다: SS7이 말한 것과 SIP가 라우팅할 수 있었던 것 — RFC 3372
게이트웨이는 레거시 시그널링 바이트를 모두 보존하면서도 통화를 잘못된 방향으로 보낼 수 있었다. 반대로 통화를 올바르게 라우팅하면서 통화에 의미를 부여했던 기능을 잃을 수도 있었다.
역사
프로토콜은 질문을 표준화했다. 누가 답하는지는 그 밖에 남겨 두었다: RFC 3367
두 브라우저가 동일한 문구를 사용자에게서 받는다. 둘 모두 유효한 CNRP 질의를 생성한다. 각각은 서로 다르게 구성된 서비스에 그 질의를 보내고, 서로 다른 자원을 받는다. 이 교환에는 잘못된 것이 하나도 없다. 불일치는 프로토콜이 시작되기 전에 이미 들어와 있었다.
역사
영어로 질문했지만, 서비스는 힌트로 들었다: RFC 3367
2002년 IETF는 언뜻 사람적인 질문—이 언어, 이 지역, 이 범주에서 이 이름에 맞는 레코드는 무엇인가—을 표준화했습니다. RFC 3367은 이런 기호(선호)를 서비스 간에 읽을 수 있게 했지만, '좋은 답'의 의미는 각 서비스에 남겨두었습니다.
역사
주소는 조각으로 조립될 수 있었다. 조각 하나하나가 실패 지점을 하나씩 더했다: RFC 3363
리졸버는 주소의 세 조각을 갖고 있었지만 답을 얻지 못했다. A6는 각 프리픽스를 독립적으로 교체 가능하게 만들었고, 그 대가로 마지막 누락된 조직을 임계 경로의 일부로 만들었다. RFC 3363은 IETF가 그 트레이드오프를 프로덕션 기본값이 아니라 실험으로 다룬 순간을 기록한다.
역사
레이블이 팩스 스트림의 이름을 붙였다. 그러나 팩스를 상호운용 가능하게 만들지는 않았다: RFC 3362
디코더는 `image/t38`을 완벽하게 인식하면서도 다음 페이지가 도착할지에 대해서는 거의 아무것도 알지 못합니다. RFC 3362가 의미를 가진 이유는 하나의 경계에서 공통 이름을 공급했다는 점, 그리고 그 문서가 이름이 경로의 나머지를 작동시킨다는 주장을 하지 않았다는 점 때문이었습니다.
역사
한 번의 재시도가 프레임을 구했다. 그 지연은 뒤의 모든 플로우의 것이었다: RFC 3366
2002년 8월, IETF는 링크 계층의 작은 선택을 인터넷 전반의 설계 문제로 드러냈습니다. 손상된 프레임은 얼마나 오래 다른 패킷을 붙잡고 있어야 할까요? 한 번의 재시도는 TCP가 종단 간 경로에 걸리기 전에 전송을 복구할 수 있습니다. 그러나 매 시도는 시간을 소모하고, 링크는 어떤 대기 트래픽이 그 시간을 감당할 수 있는지 알지 못합니다.
역사
리스가 프록시의 이름을 밝혔다. 그러나 통화 경로가 작동한다는 증거는 아니었다: RFC 3361
DHCP 응답은 SIP 클라이언트에게 시작점을 알려줄 수 있었지만, 아웃바운드 프록시를 지명하는 작은 옵션은 그 이후 경로에 대한 영수증이 아니었다. RFC 3361은 이 구분을 두 인코딩 형태로 담아냈고, 각 형태의 바이트는 이후 결정을 전혀 다른 제어 표면에 위임했다.
역사
RFC 3359: 권위 없던 목록이 두 확장의 충돌을 막은 방법
모든 IS-IS TLV 값에 그럴듯한 중앙 할당자가 존재하기 전에도, 두 확장이 같은 바이트에 서로 호환되지 않는 두 가지 의미를 가르치는 일을 막을 방법이 필요했다. RFC 3359는 주권을 내세우지 않으면서 조율을 유용하게 만들었다.
유럽·중동 기관
AS210872: 나토 물류 주소 공간은 실제로 누가 광고하는가?
루셈부르크 카펠렌에 위치한 나토 지원 및 조달 기구(NSPA)에 RIPE NCC가 할당한 /21 블록은 세계 라우팅 테이블에 단일 광고로 등장하지 않고, 기구 자체의 저조도 자율 시스템과 룩셈부르크 국영 통신사 POST Luxembourg 사이로 분할되어 나타납니다. 라우팅 데이터 수집 서비스들은 프리픽스 수에 대해 상반된 수치를 보여주지만, RIR 계정 수준에서 읽으면 표면적 모순이 공유 광고 모델로 해소됩니다.
역사
프레임은 검사를 통과했다. 그래도 라우팅 요약은 손상될 수 있었다: RFC 3358
하위 계층 검사의 성공은 프레임에 대한 영수증이었지, 라우팅 프로세스가 나중에 신뢰하는 모든 바이트에 대한 영수증은 아니었다. RFC 3358은 그 가정이 실패할 수 있는 지점에 좁은 무결성 검사를 정확히 배치했다.
역사
DNS 별칭은 서비스를 옮길 수 있지만 존재를 증명하지는 못했다: RFC 2219
1997년, `www`와 `ftp` 같은 익숙한 레이블은 기계 사이를 옮길 수 있는 서비스의 편리한 정문이었다. RFC 2219는 그 관행을 지침으로 정리하면서, 유용한 이름 힌트와 서비스가 실제로 실행 중이라는 증명 사이에 확고한 선을 그었다.
역사
손실률은 사라진 패킷의 수를 셌지만, 그것들이 함께 빠졌는지는 보여주지 못했다: RFC 3357
하나의 백분율은 전혀 다르게 느껴지는 두 패킷 스트림을 같게 묘사할 수 있습니다. RFC 3357은 평균이 버리는 순서를 보존하면서, 패턴을 진단으로 바꾸지는 않았습니다.
역사
대표자는 기관을 위해 발언했다. 결정은 워킹그룹이 내려야 했다: RFC 3356
RFC 3356는 표준화 기관이 흔히 혼동하는 문제를 풀었습니다. 한 사람이 결정 권한 없이 기관의 공식 입장만을 다른 기관에 전달하려면 어떻게 해야 하는가? 그 답은 주권 이전이 아니라 출처의 연쇄였습니다.
역사
터널은 베어러를 숨겼다. 베어러는 여전히 봉투를 정했다: RFC 3355
L2TP는 그 아래의 매체에 대체로 무관하도록 설계되었습니다. RFC 3355는 그 추상화의 대가를 보여줍니다. ATM은 내부 프로토콜의 시야에서 사라질 수 있었지만, 하나의 AAL5 가상 회선이 여전히 바깥 봉투의 크기, 정체성, 수명을 정했습니다.
역사
15개 필드는 이동할 수 있었다. 그 의미에는 여전히 로컬 계약이 필요했다: RFC 2413
1998년 더블린 코어는 성장하는 웹에 자원을 기술하기 위한 작은 공유 어휘를 제시했습니다. 의도적인 유연성 덕분에 이 어휘는 이식 가능했지만, 실제로 그 필드가 무엇을 의미하는지는 컬렉션과 검색 시스템이 판단해야 했습니다.
역사
태그는 96비트로 남았고, 그 밑의 해시가 바뀌었다: RFC 2403과 2404
IPsec의 두 변환은 그 아래의 해시가 바뀌는 동안에도 전송되는 인증자를 96비트로 유지했습니다. 이 안정된 필드는 패킷 형식을 비교 가능하게 만들었지만, 알고리즘, 키 크기, 이후의 구현 권고까지 같게 만들지는 않았습니다.