SRE engineer Bookmarks

I’m Linux system engineer and I develop in Python, Bash and Perl. I’m really interested by SRE position for that, I’m applying for SRE Engineer in Google and production Engineer in facebook. and here I share my daily bookmarks :

sre

A Method for Transmissing PPP Over Ethernet (PPPoE) (RFC2516)

Publication date : February 1999
RFC Author(s) : R.Wheeler, D.Simone, D. Carrel, J. Evarts, K. Lidl, L. Mamakos
Category : informational

The Point-to-point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links.

PPPoE has two differents stages, first one is PPP Discovery stage that contains four steps when a host discovers the MAC address of peer (Concentrator) and the PPPoE session ID.
In the fact, the Mac address and PPPoE_SESSION_ID uniquely define a ession.
The relationship between the peers is a simple client/server when a client asks server(Concentrator) for informations to establish
the session.

The Frame sent is a simple Ethernet frame where the ETHER_TYPE is set to either 0x8863 (Discovery Stage) or 0x8864 (PPP Session Stage).

Here is the Ethernet Payload for PPPoE:
[ VER:4 | TYPE:4 | CODE:8 | SESSION_ID:16 | LENGTH:16 | PAYLOAD:16 ]

Discovery Stage : Ethernet Frame have the ETHER_TYPE field set to 0x8863

1. Client to server: Initiation (PPPoE Active Discovery Initiation)
PADI:
* Host send a broadcast packet, with the code field set to 0x09
* The session id set to 0x0000

2. Server to client: Offer (PPPoE Active Disocvery Offer)
PADO:
* Access Concentrator reply to an unicast address, with code set to 0x07
* The session id set to 0x0000
* PADO packet contains AC-Name TAG, Service-Name TAG

3. Client to server: Request (PPPoE Active Discovery Request)
PADR:
* Host receive one or more PADO packet and has to choice one
* Choice is based on AC-Name or Services offred
* Host send one PADR packet to Concentrator
* Destination is the unicat Ethernet address of Cencentrator
* code field is set to 0x19 and session id is set to 0x0000

4. Server to client: Session-confirmation (PPPoE Active Discovery Session-confirmation)
PADS:
* When Access receive PADR it prepare to begin PPP session
* generate a unique session id
* reply with an unicat Ethernet address
* code field is set to 0x65
* contains exactly one TAG of TAG_TYPE Service-Name

5. Either end to other end: Termination (PADT)
* packet sent bu host or Access Concentrator
* session is established
* Destination address is unicast
* session is the SESSION_ID generated
* code field is set to 0xa7

Examples Using scapy:
1. PADI:
sendp(Ether(type=0x8863,src=”00:60:4c:72:e7:69″,dst=”ff:ff:ff:ff:ff:ff”)/PPPoED(code=0x09,sessionid=0x0000),iface=”nas0″)

PADO:
2. sendp(Ether(type=0x8863,src=”00:bf:12:fa:90:fd”, dst=”00:60:4c:72:e7:69″)/PPPoED(code=0x07,sessionid=0x0000),iface=”nas0″)

EtherIP: Tunneling Ethernet Frames in IP Datagrams (RFC3378)

Publication date : September 2002
RFC Author(s) : R.Housley, S.Hollenbeck
Category : informational

EtherIP protocol developed in 1991, and used to tunnel Ethernet and IEEE 802.3 media access control (MAC) frames (including IEEE 802.1Q [VLAN] datagrams) across an IP internet.

The EtherIP datagrams contains 16-bit header and a variable-length encapsulated Ethernet or IEEE 802.3 frame that immediately follows IP fields.

The 16-bit of EtherIP header contains two fields, the version 4-bit that must be set to 3 (0011) and 12-bit reserved reserved for future that have to be set to zero, for encapsulation and decapsulation operations. An IP datagram with a EtherIP header must set the IPv4 protocol to 97 (decimal).

The brigde-like station must listen for IP datagram that contains the protocol 97 and ignore the rest LAN frames. if this case it extract MAC from datagrams on the LAN and calculate the (FCS) frame check sequence even the IP checksum does not provide integrity protection for Ethernet/IEEE 802.3, and append the frame as part of data link layer.

One security consideration solution is to protect the IP datagram that carry EtherIP with IPsec [RFC2401].

IPv6 Router Advertisement Options for DNS Configuration (RFC6106)

Publication date  : November 2010
RFC Author(s)       : S. Park, L. Beloeil, S. Madanapalli
Category              : Standards Track

This article describe some specifications of RA DNS options, which allow  to IPv6 routers to advertise a list of DNS recursive server addresses and a list of Domain name server Search List to an IPv6 node.

RA Options are based on Neighbor Discovery (ND) for IPv6 stateless  autoconfiguration, that provide a simple way to configure mobile node in a IPv6 network and which make ability to nomadic hosts to reach Internet Services. In this document (section 5) the IPv6 DNS configuration defines two ND  options :

1. The Recursive DNS Server (RDNSS) Contains one or more IPv6 addresses of recursive DNS servers, this Option Format contain 4 field :
Type (8-bit), Length (8-bit), Reserved(16-bit), Lifetime(32-bit) and Addresse of IPv6 Recursive DNS servers (128-bit)

2. The DNS Search List (DNSSL) Contains one or more domains name, this Option Format contain 4 field :
Type (8-bit), Length (8-bit), Reserved(16-bit), Lifetime(32-bit) and Domain Names of DNS Search List (128-bit)

Section 5.1, define that a packet with lifetime value set all one bits (0xffffffff) represents infinity, which mean that the node must keep the DNS parameters, until next update.

Section 5.2, define that a packet with lifetime value set to zero means that RDNSS address must no longer be used.

The RFC describe also, that storing RDNSS addresses from at least two different sources is highly recommended.

Source : https://tools.ietf.org/html/rfc6106