Networking Layers Heterogeneity: Abstraction: Flexibility: Multiple link-types App is link-type agnostic E.g. multiple Transports, e2e “ hidden ” by L3 Application Application Transp. Transp. Transp. Transp. Network Network Network Link Link Link Link Link Link Avian ATM Ethernet TokenRing Carrier 1
Shortest Path Routing Find “ good ” paths from source w to destination router 5 5 3 1 v 2 3 z 2 u 2 1 x 1 y 2
Destination-Based Forwarding Dst Egress Link F 2 B 1 Dst Egress Link C 2 A 1 D 1 B 2 E 1 C 3 D 1 A 1 E 3 2 D 1 B F 2 E 3 C 3
Tunnels Mark Townsley 4 4
Objectives • Understand how and why tunnels are used in the Internet • Understand the basic components of a tunneling protocol • Walk through the specific case of tunneling PPP 5
We build them… When and where we think we need them for specific purposes 6
What goes in should come out.. Tunnels act like the layer below that which they are carrying Often not perfectly, but “good enough” for a specific purpose IP tunnels act like Data Link Layers 7
They provide us a Layer of Indirection All problems in computer science can be solved by another level of indirection… …except for the problem of too many levels of indirection - David Wheeler 8
They have a 9
Tunneling Protocol Components • Identifying and synchronizing the endpoints IP address, Session ID, etc. Control Protocols, mapping algorithms, manual config • Bits on the wire and forwarding Typically involves encapsulation, but encapsulation != tunneling • Also: Troubleshooting, diagnostics, etc… 10
Tunneling Protocol Components • Identifying and synchronizing the endpoints “MAP” IP address, Session ID, etc. Control Protocols, mapping algorithms, manual config • Bits on the wire and forwarding Typically involves encapsulation, but encapsulation != tunneling • Also: Troubleshooting, diagnostics, etc… 10
Tunneling Protocol Components • Identifying and synchronizing the endpoints “MAP” IP address, Session ID, etc. Control Protocols, mapping algorithms, manual config • Bits on the wire and forwarding + Typically involves encapsulation, but encapsulation != tunneling • Also: Troubleshooting, diagnostics, etc… 10
Tunneling Protocol Components • Identifying and synchronizing the endpoints “MAP” IP address, Session ID, etc. Control Protocols, mapping algorithms, manual config • Bits on the wire and forwarding + Typically involves encapsulation, but encapsulation != tunneling “ENCAP” • Also: Troubleshooting, diagnostics, etc… 10
Tunnels – always a tradeoff • Indirection Good: Scalability, “Mobility”, “Traffic Engineering”, etc. Bad: Managing when and where to indirect to (mapping) • Adaptation Good: Overlays allow transition to new technologies, sunsetting old Bad: Layer violation, introduces emulation artifacts • Obfuscation Good: The “P” in VPNs Bad: Breaks Deep Packet Inspection, Netflow, SPF, etc. 11
Indirection – Mobile IP 12
Indirection – RSVP-TE 13
Indirection – RSVP-TE 14
Indirection – RSVP-TE 15
MPLS Encapsulation (Labels) Data Link (Ethernet, PPP, Sonet, etc..) Label Exp S TTL Label Exp S TTL Label Exp S TTL Label Exp S TTL MPLS PDU (IP packet, L2-Frame, etc) 16 16
Adaptation – IPv4 in IPv6 • While incompatible on the wire, IPv4 and IPv6 are both still “philosophically” IP 17
Dual Stack Transition Leap IPv4-Only Network Dual Stack Network NAT IPv4-Only IPv6-Only Network PE PE CE NAT CE IPv4-Only Dual-Stack IPv6-Only Users Users Users 18
Transition Steps Instead of Leaps… IPv4-Only Dual Stack Dual Stack Dual Stack Network Network Network Network Dual Stack Network 6 ↔ 4 NAT IPv4-Only IPv4 IPv6 IPv6-Only Network Only Only PE PE CE CE NAT CE CE Dual-Stack IPv4-Only Dual-Stack IPv6-Only Dual-Stack Users Users Users Users Users 19
Evolution of MAP in the IETF 20
Adaptation - Generic Routing Encapsulation (GRE) 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 Version Ve Versio rsion IHL IHL IHL TO TOS TOS S Tota Total len tal length length th Tunnel IP Identifica Iden entification ication ion Flags Flags Flags Frag Fragme ragment o ment offse t offset set TTL TTL TTL Pro Protoco Protocol == ocol == 0x2 l == 0x2F == 0x2F (GR F (GRE) RE) Header Hea eader che er checksu checksum cksum m Sou Source Source IP rce IP add P address dress (Lo ss (Local (Local add cal address ddress on ss on PE n PE rou PE router) uter) r) Desti Destinati stination I ation IP ad IP addre address (L ress (Loca ss (Local ad cal addre address o ress on PE ss on PE ro PE route PE router) ter) C R K S s Recur Flags Version Protocol (0x800 for IP) Checksum (O cksum (Optional) Offset (Optional) Key (Opt y (Optional) GRE Sequ Sequence Numb Number (Optional) Routing : uting ::: (Variable riable length, Optional) Address Family SRE Offset SRE Length Routing Information (V tion (Variable length) ::: 21 21
MPLS over GRE 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 Ve Versio Version rsion IHL IHL IHL TO TOS TOS S Tota Total len tal length length th Tunnel IP Identifica Iden entification ication ion Flags Flags Flags Frag Fragme ragment o ment offse t offset set TTL TTL TTL Protoco Pro Protocol == ocol == 0x2 l == 0x2F == 0x2F (GR F (GRE) RE) Hea Header eader che er checksu checksum cksum m Source IP Source Sou rce IP add P address dress (Lo ss (Local (Local add cal address ddress on ss on PE n PE rou PE router) uter) r) Destinati Desti stination I ation IP ad IP addre address (L ress (Loca ss (Local ad cal addre address o ress on PE ss on PE ro PE route PE router) ter) GRE 0 0 0 0 0 Rec = 0 Flags = 0 Ver = 0 Protocol = 0x8847 Label Exp S TTL MPLS PDU MPLS PDU (IP packet for RFC 2547) MPLS VPN Label 22 22
MPLS over IP 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 Ve Versio Version rsion IHL IHL IHL TO TOS TOS S Total len Tota tal length length th Tunnel IP Iden Identifica entification ication ion Flags Flags Flags Frag Fragme ragment o ment offse t offset set TTL TTL TTL Pro Protoco Protocol == col == MPL == MPLS MPLS (TBD MPLS (TBD) (TBD) Hea Header eader che er checksu checksum cksum m Sou Source Source IP rce IP add P address dress (Lo ss (Local (Local add cal address ddress on ss on PE n PE rou PE router) uter) r) Desti Destinati stination I ation IP ad IP addre address (L ress (Loca ss (Local ad cal addre address o ress on PE ss on PE ro PE route PE router) ter) Label Exp S TTL MPLS PDU MPLS PDU (IP packet for RFC 2547) MPLS VPN Label 23 23
PPP 24
PPP Link Phases as “Layers” 25
PPP Link Phases 26
PPP State 27
PPP Configuration Negotiation Messages • Configure-Request “The system sending Configure-Request is telling the peer system that it is willing to receive data sent with the enclosed options enabled.” • Configure-Ack “if all of the options are acceptable, the peer then responds with Configure-Ack with exactly the same option list as given in the Configure-Request to indicate that all of the enclosed options were acceptable and that all are now enabled.” • Configure-Nak “If some of the options were recognized but unacceptable with the supplied parameters, the peer would then respond with a Configure-Nak containing only the offending options and a suggested modified value for the parameters (called a hint). The receiver of the Configure- Nak then should decide if the hinted value is acceptable and, if so, send a new Configure- Request reflecting the requested changes plus the original values for the unchanged options.” • Configure-Reject “If the peer does not recognize (or administratively prohibits) one or more of the options in the Configure-Request message, it must return just these options in a Configure- Reject message and the original sender must then remove the options from sub- sequent Configure-Request messages.” 28
PPP Negotiation Example 29
30
6rd 30
L2TP 6rd UDP IP 30
30
L2TP 30
L2TP 30
L2TP – “Voluntary Tunneling” http://www.interpeak.com/files/l2tp.pdf 31
L2TP – “Compulsory Tunneling” http://www.interpeak.com/files/l2tp.pdf 32
L2TP Scale Broadband Non-PPP Access/ISP Client VPNs decoupling IPv6 “PPTP “L2F Trans replacement” replacement” Purpose 33
5218 Case Study: L2TP Factor L2TP Incremental deployability Yes Positive net value Yes No close competitors No – L2F, PPTP, IPsec Good technical design Average Threats sufficiently mitigated No (only with Ipsec) Restriction-free Yes Open spec availability Yes Open maintenance process Yes Extensible Yes (TLVs, L2TPv3) No scalability bound No (64K sessions within a Tunnel) 34
Recommend
More recommend
