Angelo van der Sijpt - How well do you know your network stack? - Codemotion Amsterdam 2019

How well do you know your
network stack?
Angelo van der Sijpt
Amsterdam | April 2-3, 2019

Fellow @ Luminis Eindhoven

Running, OCR, Krav Maga

@_angelos 
angelo.vandersijpt@luminis.eu

https://www.iso.org/standard/20269.html

Network Working Group Steve Crocker
Request for Comments: 1 UCLA
7 April 1969
Title: Host Software
Author: Steve Crocker
Installation: UCLA
Date: 7 April 1969
Network Working Group Request for Comment: 1
CONTENTS
INTRODUCTION
I. A Summary of the IMP Software
Messages
Links
IMP Transmission and Error Checking
Open Questions on the IMP Software
II. Some Requirements Upon the Host-to-Host Software
Simple Use
Deep Use
Error Checking
III. The Host Software
Establishment of a Connection
High Volume Transmission
A Summary of Primitives
Error Checking
Closer Interaction
Open Questions
Crocker [Page 1]
Network Working Group
Request for Comments: 1
Title: Host Software
Author: Steve Crocker
Installation: UCLA
Date: 7 April 1969
Network Working Group Request for Com
CONTENTS
INTRODUCTION
I. A Summary of the IMP Software
Messages
Links
IMP Transmission and Error Checking
Open Questions on the IMP Software
II. Some Requirements Upon the Host-to-Host Softw
Simple Use
Deep Use
Error Checking
https://tools.ietf.org/rfc/index

https://en.wikipedia.org/wiki/Modular_connector
https://en.wikipedia.org/wiki/Twisted_pair
https://en.wikipedia.org/wiki/Category_6_cable

Class Channel Category
A 100 kHz 1
B 1 MHz 2
C 16 MHz 3
D 100 MHz 5e
E 250 MHz 6
EA 500 MHz 6A
F 600 MHz 7
FA 1000 MHz 7A

802.3ab
1000BASE-T “Gigabit ethernet”

data
symbols 
PAM5
110 010 001 111
00 0101 10
voltages-2 1 2 0
pairs

destination source type
MAC
address

destination source type
EtherType Protocol
0x0800 IPv4
0x0806 ARP
0x8137 IPX
0x86DD IPv6

destination source typepreamble payload crc gap
preamble
crc
gap
10101010 10101010 10101010 10101010 10101010 10101010 10101010 10101011
4 byte checksum
EOD symbol + 
12 bytes silence

RFC: 791
INTERNET PROTOCOL
DARPA INTERNET PROGRAM
PROTOCOL SPECIFICATION
September 1981
prepared for
Defense Advanced Research Projects Agency
Information Processing Techniques Office
1400 Wilson Boulevard
Arlington, Virginia 22209
by
Information Sciences Institute
University of Southern California
4676 Admiralty Way
Marina del Rey, California 90291
INTERNET PROTOCOL
September 1981
prepared for
Defense Advanced Research Projects Agency
Information Processing Techniques Office
1400 Wilson Boulevard
Arlington, Virginia 22209

version
IHL
version
DSCP
ECN
Length
Ident
Flags
Fragoﬀs
TTL
Protocol
Checksum
source destination

TTL Protocol source destination
Number Protocol
1 ICMP
6 TCP
115 L2TP
4 IPv4 encapsulation

11000000
192
10101000
168
00000010
2
10010110
150
ip address
11111111 11111111 11111111 00000000 netmask
192.168.2.0/24 CIDR
network nr
11000000
192
10101000
168
00000010
2
host nr
10010110
150

.3 .150 .1
192.168.2.0/24
.5
10.0.1.0/24
192.168.2.150 192.168.2.3

.3 .150 .1
192.168.2.0/24
.5
10.0.1.0/24
192.168.2.150 192.168.2.3
0c:4d:e9:b9:7b:14 9c:93:4e:6c:6d:65

.3 .150 .1
192.168.2.0/24
.5
10.0.1.0/24
192.168.2.150 10.0.1.5

.3 .150 .1
192.168.2.0/24
.5
10.0.1.0/24
192.168.2.150 10.0.1.5
0c:4d:e9:b9:7b:14 80:2a:a8:4d:3b:c1

.3 .150 .1
192.168.2.0/24
.5
10.0.1.0/24
192.168.2.150 10.0.1.5
0c:4d:e9:b9:7b:14 f0:9f:c2:2f:7a:fb

.3 .150 .1
192.168.2.0/24
.5
10.0.1.0/24

.3 .150 .1
192.168.2.0/24
.5
10.0.1.0/24
63

.3 .150 .1
192.168.2.0/24
.5
10.0.1.0/24
62

5 4 13 2
143
4 12
2!
45 3x 35✔✔

5 4 13 2
143
4 12
2!
45 3x
355!✔✔✔ ✔✔

Fielding, et al Standards Track [Page 1]
Network Working Group R. Fielding
Request for Comments: 2616 UC Irvine
Obsoletes: 2068 J. Gettys
Category: Standards Track Compaq/W3C
J. C. Mogul
Compaq
H. Frystyk
W3C/MIT
L. Masinter
Xerox
P. Leach
Microsoft
T. Berners-Lee
W3C/MIT
June, 1999
Hypertext Transfer Protocol -- HTTP/1.1
Status of this Memo
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and
suggestions for improvements. Please refer to the current edition of the “Internet Official Protocol Standards” (STD
1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (1999). All Rights Reserved.
Abstract
The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia
information systems. It is a generic, stateless, protocol which can be used for many tasks beyond its use for
hypertext, such as name servers and distributed object management systems, through extension of its request
methods, error codes and headers [47]. A feature of HTTP is the typing and negotiation of data representation,
allowing systems to be built independently of the data being transferred.
HTTP has been in use by the World-Wide Web global information initiative since 1990. This specification defines
the protocol referred to as “HTTP/1.1”, and is an update to RFC 2068 [33].

5.1.1 Method
The Method token indicates the method to be performed on the resource identified by the Reque
method is case-sensitive.
Method = "OPTIONS" ; Section 9.2
| "GET" ; Section 9.3
| "HEAD" ; Section 9.4
| "POST" ; Section 9.5
| "PUT" ; Section 9.6
| "DELETE" ; Section 9.7
| "TRACE" ; Section 9.8
| "CONNECT" ; Section 9.9
| extension-method
extension-method = token
The list of methods allowed by a resource can be specified in an Allow header field (section 14.7)
of the response always notifies the client whether a method is currently allowed on a resource, since
allowed methods can change dynamically. An origin server SHOULD return the status code 405 (M
Allowed) if the method is known by the origin server but not allowed for the requested resource, an
Implemented) if the method is unrecognized or not implemented by the origin server. The methods
MUST be supported by all general-purpose servers. All other methods are OPTIONAL; however, if
methods are implemented, they MUST be implemented with the same semantics as those specified i
5.1.2 Request-URI
The Request-URI is a Uniform Resource Identifier (section 3.2) and identifies the resource upon
the request.
Request-URI = "*" | absoluteURI | abs_path | authority
The four options for Request-URI are dependent on the nature of the request. The asterisk “*” m
request does not apply to a particular resource, but to the server itself, and is only allowed when the
does not necessarily apply to a resource. One example would be
Fielding, et al Standards Track [Pa
| extension-method
extension-method = token
The list of methods allowed by a resource can be specified in an Allow header field (section 14.7). T
of the response always notifies the client whether a method is currently allowed on a resource, since th
allowed methods can change dynamically. An origin server SHOULD return the status code 405 (Met
Allowed) if the method is known by the origin server but not allowed for the requested resource, and 5
Implemented) if the method is unrecognized or not implemented by the origin server. The methods GE
MUST be supported by all general-purpose servers. All other methods are OPTIONAL; however, if th
methods are implemented, they MUST be implemented with the same semantics as those specified in
5.1.2 Request-URI
The Request-URI is a Uniform Resource Identifier (section 3.2) and identifies the resource upon w
the request.
Request-URI = "*" | absoluteURI | abs_path | authority
The four options for Request-URI are dependent on the nature of the request. The asterisk “*” mea
request does not apply to a particular resource, but to the server itself, and is only allowed when the m
does not necessarily apply to a resource. One example would be
Fielding, et al Standards Track [Pag
quoted-pair = "" CHAR
3 Protocol Parameters
3.1 HTTP Version
HTTP uses a “<major>.<minor>” numbering scheme to indicate versions of the protocol. The protocol
policy is intended to allow the sender to indicate the format of a message and its capacity for understan
HTTP communication, rather than the features obtained via that communication. No change is made to
number for the addition of message components which do not affect communication behavior or which
extensible field values. The <minor> number is incremented when the changes made to the protocol ad
which do not change the general message parsing algorithm, but which may add to the message semant
additional capabilities of the sender. The <major> number is incremented when the format of a messag
protocol is changed. See RFC 2145 [36] for a fuller explanation.
The version of an HTTP message is indicated by an HTTP-Version field in the first line of the mess
HTTP-Version = "HTTP" "/" 1*DIGIT "." 1*DIGIT
Note that the major and minor numbers MUST be treated as separate integers and that each MAY be in
higher than a single digit. Thus, HTTP/2.4 is a lower version than HTTP/2.13, which in turn is lower th
HTTP/12.3. Leading zeros MUST be ignored by recipients and MUST NOT be sent.
An application that sends a request or response message that includes HTTP-Version of “HTTP/1.1”
least conditionally compliant with this specification. Applications that are at least conditionally complia
specification SHOULD use an HTTP-Version of “HTTP/1.1” in their messages, and MUST do so for a
| Upgrade ; Section 14.42
| Via ; Section 14.45
| Warning ; Section 14.46
header field names can be extended reliably only in combination with a change in the protocol version.
, new or experimental header fields may be given the semantics of general header fields if all parties in the
cation recognize them to be general-header fields. Unrecognized header fields are treated as entity-header
quest
message from a client to a server includes, within the first line of that message, the method to be applied to
rce, the identifier of the resource, and the protocol version in use.
Request = Request-Line ; Section 5.1
*(( general-header ; Section 4.5
| request-header ; Section 5.3
| entity-header ) CRLF) ; Section 7.1
CRLF
[ message-body ] ; Section 4.3
equest-Line
uest-Line begins with a method token, followed by the Request-URI and the protocol version, and
ith CRLF. The elements are separated by SP characters. No CR or LF is allowed except in the final CRLF
.
Request-Line = Method SP Request-URI SP HTTP-Version CRLF
ethod
hod token indicates the method to be performed on the resource identified by the Request-URI. The
RFC 2616 HTTP/1.1 J
Recipients of an HTTP/1.0 request that lacks a Host header field MAY attempt to use heuristics
of the URI path for something unique to a particular host) in order to determine what exact resour
requested.
5.3 Request Header Fields
The request-header fields allow the client to pass additional information about the request, and abo
to the server. These fields act as request modifiers, with semantics equivalent to the parameters on
language method invocation.
request-header = Accept ; Section 14.1
| Accept-Charset ; Section 14.2
| Accept-Encoding ; Section 14.3
| Accept-Language ; Section 14.4
| Authorization ; Section 14.8
| Expect ; Section 14.20
| From ; Section 14.22
| Host ; Section 14.23
RFC 2616 HTTP/1.1 June, 1999
| Upgrade ; Section 14.42
| Via ; Section 14.45
| Warning ; Section 14.46
General-header field names can be extended reliably only in combination with a change in the protocol version.
However, new or experimental header fields may be given the semantics of general header fields if all parties in the
communication recognize them to be general-header fields. Unrecognized header fields are treated as entity-header
fields.
5 Request
A request message from a client to a server includes, within the first line of that message, the method to be applied to
the resource, the identifier of the resource, and the protocol version in use.
Request = Request-Line ; Section 5.1
| request-header ; Section 5.3
CRLF

FC 2616 HTTP/1.1 June, 1999
he first digit of the Status-Code defines the class of response. The last two digits do not have any
ategorization role. There are 5 values for the first digit:
• 1xx: Informational - Request received, continuing process
• 2xx: Success - The action was successfully received, understood, and accepted
• 3xx: Redirection - Further action must be taken in order to complete the request
• 4xx: Client Error - The request contains bad syntax or cannot be fulfilled
• 5xx: Server Error - The server failed to fulfill an apparently valid request
he individual values of the numeric status codes defined for HTTP/1.1, and an example set of corresponding
eason-Phrase’s, are presented below. The reason phrases listed here are only recommendations -- they MAY
e replaced by local equivalents without affecting the protocol.
Status-Code =
"100" ; Section 10.1.1: Continue
| "101" ; Section 10.1.2: Switching Protocols
| "200" ; Section 10.2.1: OK
| "201" ; Section 10.2.2: Created
communication recognize them to be request-header fields. Unrecognized header fields are treated as entity-header
fields.
6 Response
After receiving and interpreting a request message, a server responds with an HTTP response message.
Response = Status-Line ; Section 6.1
| response-header ; Section 6.2
CRLF
6.1 Status-Line
The first line of a Response message is the Status-Line, consisting of the protocol version followed by a
numeric status code and its associated textual phrase, with each element separated by SP characters. No CR or LF is
allowed except in the final CRLF sequence.
Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF
6.1.1 Status Code and Reason Phrase
The Status-Code element is a 3-digit integer result code of the attempt to understand and satisfy the request.
These codes are fully defined in section 10. The Reason-Phrase is intended to give a short textual description of
the Status-Code. The Status-Code is intended for use by automata and the Reason-Phrase is intended
for the human user. The client is not required to examine or display the Reason-Phrase.

Network Working Group P. Mockapetris
Request for Comments: 1035 ISI
November 1987
Obsoletes: RFCs 882, 883, 973
DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION
1. STATUS OF THIS MEMO
This RFC describes the details of the domain system and protocol, and
assumes that the reader is familiar with the concepts discussed in a
companion RFC, "Domain Names - Concepts and Facilities" [RFC-1034].
The domain system is a mixture of functions and data types which are an
official protocol and functions and data types which are still
experimental. Since the domain system is intentionally extensible, new
data types and experimental behavior should always be expected in parts
of the system beyond the official protocol. The official protocol parts
include standard queries, responses and the Internet class RR data
formats (e.g., host addresses). Since the previous RFC set, several
definitions have changed, so some previous definitions are obsolete.
Experimental or obsolete features are clearly marked in these RFCs, and
such information should be used with caution.
The reader is especially cautioned not to depend on the values which
appear in examples to be current or complete, since their purpose is
primarily pedagogical. Distribution of this memo is unlimited.
Table of Contents
1. STATUS OF THIS MEMO 1
2. INTRODUCTION 3
2.1. Overview 3
2.2. Common configurations 4
2.3. Conventions 7
2.3.1. Preferred name syntax 7
2.3.2. Data Transmission Order 8
2.3.3. Character Case 9
2.3.4. Size limits 10
3. DOMAIN NAME SPACE AND RR DEFINITIONS 10
3.1. Name space definitions 10
3.2. RR definitions 11
3.2.1. Format 11
3.2.2. TYPE values 12
3.2.3. QTYPE values 12
3.2.4. CLASS values 13
Mockapetris [Page 1]
7
DNS
Obsoletes: RFCs 882, 883, 973
DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION
1. STATUS OF THIS MEMO
This RFC describes the details of the domain system and protoc
assumes that the reader is familiar with the concepts discusse
companion RFC, "Domain Names - Concepts and Facilities" [RFC-1
The domain system is a mixture of functions and data types whi
official protocol and functions and data types which are still
experimental. Since the domain system is intentionally extens
data types and experimental behavior should always be expected
of the system beyond the official protocol. The official prot
include standard queries, responses and the Internet class RR
formats (e.g., host addresses). Since the previous RFC set, s
definitions have changed, so some previous definitions are obs
Experimental or obsolete features are clearly marked in these
such information should be used with caution.
The reader is especially cautioned not to depend on the values
appear in examples to be current or complete, since their purp

7
6
5
4
3
2
1
DHCP
DNS
Switch
Switch
Gateway
Ziggo
…
Loadbalancer
Webserver
Switch
Applicationserver

7
6
5
4
3
2
1 1 11801568
802.3ab
RFC: 791
INTERNET PROTOCOL
RFC: 791
INTERNET PROTOCOL
September 1981
Request For Comments: 826
An Ethernet Address Resoluti
-- or --
Converting Network Protocol
to 48.bit Ethernet Add
An Ethernet Address Resolution Protocol
-- or --
Converting Network Protocol Addresses
to 48.bit Ethernet Address
for Transmission on
Ethernet Hardware
RFC: 793
TRANSMISSION CONTROL PROTOCOL
RFC: 793
September 1981
J. C. Mogul
Compaq
H. Frystyk
W3C/MIT
L. Masinter
Xerox
P. Leach
Microsoft
T. Berners-Lee
W3C/MIT
June, 1999
Status of this Memo
Copyright Notice
Abstract
P. Leach
Microsoft
T. Berners-Lee
W3C/MIT
June, 1999
Status of this Memo
Copyright Notice
Abstract

7
6
5
4
3
2
1 1 11801568
802.3ab
RFC: 791
INTERNET PROTOCOL
RFC: 791
INTERNET PROTOCOL
September 1981
An Ethernet Address Resoluti
-- or --
Converting Network Protocol
to 48.bit Ethernet Add
An Ethernet Address Resolution Protocol
-- or --
Converting Network Protocol Addresses
to 48.bit Ethernet Address
for Transmission on
Ethernet Hardware
RFC: 793
RFC: 793
September 1981
J. C. Mogul
Compaq
H. Frystyk
W3C/MIT
L. Masinter
Xerox
P. Leach
Microsoft
T. Berners-Lee
W3C/MIT
June, 1999
Status of this Memo
Copyright Notice
Abstract
P. Leach
Microsoft
T. Berners-Lee
W3C/MIT
June, 1999
Status of this Memo
Copyright Notice
Abstract
IPX/SPXXNS
DECnet


@_angelos
1
2
3
4
5
6
7
Cabling
Wire protocols
Ethernet
IP
ARP
2,5
TCP
HTTPDOCSIS
DNS
DHCP
UDP
Connectors, voltages, Hz
Encoding, using pairs
MAC, relay, hub vs switch
IP over Ethernet, subnets, routing, TTL, NAT
Address resolution exchange
Reliable messaging, sliding window, ports
Methods, status codes

Angelo van der Sijpt - How well do you know your network stack? - Codemotion Amsterdam 2019

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a Angelo van der Sijpt - How well do you know your network stack? - Codemotion Amsterdam 2019

Semelhante a Angelo van der Sijpt - How well do you know your network stack? - Codemotion Amsterdam 2019 (20)

Mais de Codemotion

Mais de Codemotion (20)

Último

Último (20)

Angelo van der Sijpt - How well do you know your network stack? - Codemotion Amsterdam 2019