주요 분야
인터넷 인프라
‘주요 분야’ 패싯에서 인터넷 인프라 인텔리전스는 보고 내용을 주 영역별로 묶어, 독자가 인터넷 인프라, 거버넌스, 연결성 시장 또는 디지털 자본 가운데 특정 영역을 집중적으로 따라갈 수 있도록 합니다. 이 페이지는 별도 카테고리 페이지에 나뉘어 있을 수 있는 관련 기사, 공개 증거, 기관, 기업, 인물, 지역적 노출, 운영 의존성, 시장 맥락을 한데 모읍니다. 아울러 해당 영역, 예상 행위자 유형, 시장 또는 거버넌스 맥락, 그리고 신호를 비교할 때 독자가 활용해야 할 출처 자료를 설명합니다. 운영자, 분석가, 거버넌스 분야 독자는 같은 영역이 이벤트, 프로필, 시장 변화, 공개 출처 증거, 지역 의존성, 보다 장기적인 주기의 인프라 의사결정 전반에서 시간에 따라 어떻게 나타나는지 살펴볼 수 있습니다.
역사
발신자는 수신자에게 익명이었지 프라이버시 서비스에게는 아니었다: RFC 3323
RFC 3323은 익명성을 소멸로 정의하지 않았습니다. 한 주체가 신원을 못 보게 되는 대신, 다른 주체가 그것을 보고, 제거하고, 그 주변으로 라우팅할 것이라는 신뢰 위에 놓인 경로를 정의했습니다.
역사
상대에게는 익명, 다이얼로그 안에서는 도달 가능: RFC 3323
RFC 3323은 SIP 발신자를 지워 버리지 않았다. 더 좁은 질문을 던졌다. 수신자가 어떤 신원 정보를 보아야 하고, 대화가 계속되려면 서비스가 어떤 상태를 보존해야 하는가?
역사
4.131초의 호출 설정은 모델 안에만 존재했다: RFC 3322
RFC 3322는 기억에 남는 총액을 산출했습니다: SIP/SDP 신호 지연 4,131밀리초. 이 수치는 가정이 정밀했기 때문에 정밀해 보였습니다. 스톱워치 측정값이 아니었고, 문서 자체가 그 차이를 이례적으로 솔직하게 밝혔습니다.
역사
확인 응답은 상태가 존재했다고 말했다. 아직도 존재한다고는 말하지 않았다: RFC 3321
SigComp의 명시적 확인 응답은 압축기가 원격 상태에 의존할 수 있게 해 주었다. 더 어려운 문제는 그 다음 메시지에서 나타났다. 정직한 확인 응답이, 그것이 설명하는 상태가 상대 엔드포인트에서 이미 삭제된 뒤에도 로컬 메모리에 남아 있을 수 있다는 점이다.
역사
메시지가 해제되었다고 해서 영구 상태를 얻는 것은 아니다: RFC 3320
SigComp는 발신자가 신호 메시지용 소형 압축 해제 프로그램을 제공할 수 있게 했다. RFC 3320의 더 중요한 경계는 그 프로그램이 실행된 뒤에 있었다. 해제된 메시지라도 후속 메시지를 위한 상태를 남길 권한은 여전히 부여받지 못할 수 있었다.
역사
별표는 하나 이상의 정책에 일치할 수 있었다: RFC 3318
RFC 3318의 가장 작은 문자 하나가 큰 운영상의 약속을 담고 있었습니다. 별표 하나가 정책 서버가 모든 인터페이스 조합을 일일이 명명하지 않게 해주었지만, 동시에 두 규칙이 같은 인터페이스를 주장하게 만들 수도 있었습니다.
역사
DHCPv6는 SIP 프록시를 찾을 수 있었지만 통화를 걸 수는 없었다: RFC 3319
DHCPv6 응답은 SIP 클라이언트에게 도메인 이름, IPv6 주소, 또는 둘 모두로 구성된 순서가 지정된 로컬 아웃바운드 프록시 목록을 건네줄 수 있었습니다. 그것은 다음 제어 평면 홉을 찾는 방법이지, 누군가가 등록했거나 통화가 연결되었거나 음성이 흐를 것이라는 증거가 아니었습니다.
역사
애플리케이션이 라우터 도달 가능성을 증명할 수 있었다: RFC 3316
초기 셀룰러 IPv6 링크에서 원격 애플리케이션의 응답은 무선 계층 프로브를 절약할 수 있었다. 단, 최근 송신한 패킷에 관한 한 가지 정확한 사실을 증명했기 때문이다.
역사
링크에 MAC 주소는 없었다. 그래도 호스트는 도달 가능성을 확인해야 했다: RFC 3316
GPRS나 UMTS 링크에서 IPv6 호스트는 라우터의 링크 계층 주소를 묻지 않아도 되었습니다. 풀어야 할 그런 주소가 없었기 때문입니다. 그러나 라우터에 도달할 수 있는지는 여전히 알아야 했고, 때로는 새 프로브보다 저렴하게 다른 프로토콜의 응답이 그 질문에 답할 수 있었습니다.
역사
더 빠른 Reply가 아무도 쓰지 않는 임대를 남길 수 있다: RFC 3315
2003년 DHCPv6는 빠른 경로를 단지 아낄 패킷 수가 아니라, 네트워크 자원을 언제 확정할지에 대한 선택으로 만들었습니다.
역사
프레임 종료 비트는 사라진 패킷과 함께 사라질 수 있었다: RFC 3189
수신 측은 하나의 깔끔한 사실, 즉 화면이 완성되었다는 사실을 원했다. RFC 3189는 그 소식을 마지막 패킷의 마커 비트에 담으면서도, 그 소식을 실은 패킷이 바로 네트워크에서 유실될 수 있는 패킷일 수 있다고 경고했다. 편리한 신호는 지연을 줄일 수는 있었지만, 프레임이 어디서 끝나는지에 대한 권위가 될 수는 없었다.
역사
HTTP 라이브러리는 상호운용성 계획이 아니었다: RFC 3205
2002년 프로토콜 설계자들은 설치된 기반 때문에 HTTP를 빌리려 했다. 브라우저, 서버 코드, 보안 기술, 기존 네트워크 경계를 통한 접근이 그 이유였다. RFC 3205는 그 거래를 거부하지 않았다. 대신 프록시, 캐시, 일반 HTTP 소프트웨어가 애플리케이션과 다른 의미를 만났을 때 무엇을 할지 등 그 거래에 딸려 오는 가정을 설계자가 책임지라고 요구했다.
역사
RFC 1180은 TCP/IP를 설명한 뒤 독자를 표준으로 되돌려 보냈다
1991년 1월, T.J. Socolofsky와 C.J. Kale은 네트워크 전문가들에게 IP 데이터그램이 한 호스트에서 라우터를 거쳐 다른 호스트에 이르는 과정을 따라갈 수 있는 실용적 방법을 제시했다. 동시에 뚜렷한 선을 그었다. 이 메모는 TCP/IP를 설명했을 뿐, 정의하지는 않았다.
역사
방화벽은 '아니오'라고 말할 수 있었다. 대화를 깨뜨리도록 허락된 것은 아니었다: RFC 2979
2000년 10월, 하나의 Informational RFC가 패킷 필터가 자주 혼동해 온 경계를 그었다. 사이트는 보안상의 이유로 트래픽을 거부할 수 있지만, 방화벽이 합법적이고 표준을 준수하는 통신을 우연히 실패하게 만들어서는 안 된다는 것이었다. 이 구분은 수리 책임을 모든 애플리케이션이 아닌 중개 장치에 배정했다.
역사
보안 링크도 의심스러운 MASC 주장을 릴레이할 수 있었다: RFC 2909
MASC는 멀티캐스트 주소 범위를 임시적이고 중첩된 주장으로 배분했다. 2000년의 보안 절은 다른 경계를 지적했다: 인접 피어를 보호하는 것이 릴레이된 모든 갱신을 신뢰할 수 있게 만들지는 않는다는 것이었다.
스토리
APNIC, 로드밸런서 드레인 오작동으로 인한 8개 서비스 장애로 규명
APNIC은 한 로드밸런서 노드를 대상으로 해야 할 유지보수 단계가 다른 노드에 실행되어 8개 서비스에 장애가 발생했다고 밝혔습니다. 공지는 시작·종료 시각이 17분 차이인데도 소요 시간을 15분으로 표기했습니다.
역사
AS 하나, 멀티캐스트 주소 256개, 그리고 4바이트 한계
GLOP은 기존 네트워크 번호에서 정적 멀티캐스트 블록을 계산 가능하게 만들었습니다. 그룹 주소를 고정해야 할 때 유용했지만, 빌려온 2바이트 AS 필드만큼만 유연했습니다.
역사
IPv6 /48은 시작점이었지, 모든 사이트의 크기는 아니었다
IPv6 /48 이야기의 핵심은 IETF가 그 크기가 너무 크다는 사실을 발견한 것이 아니다. 하나의 깔끔한 아키텍처 권고가, 서로 다른 종류의 실제 네트워크가 같은 프리픽스 표 안에 들어가야 하는 상황에서 곤란해졌다는 것이다.
역사
IETF가 신규 참여자를 위축시킬 수 있던 규범 문장을 삭제한 이유
2014년 IETF의 개정은 행동 지침을 새로 고치는 데 그치지 않았다. 신규 참여자에게 던진 한 경고 문장이 참여를 주저하게 만들 수 있다고 기록하고 그 문장을 삭제했다.
역사
DNS MIB는 배포에 도달하지 못했다. RFC 3197이 그 점을 만든 셈이다.
RFC 3197은 드문 표준 회고 문서입니다. 두 개의 DNS 관리 MIB가 배포를 찾지 못했다고 밝히고, 그 부재를 DNS가 아니라 프로젝트 자체에 대한 증거로 다룹니다.