Networking Layers Heterogeneity: Abstraction: Flexibility: - - PowerPoint PPT Presentation
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
Application Network
ATM Ethernet
Network
Avian Carrier
Application Transp. Network
TokenRing Abstraction: App is link-type agnostic Heterogeneity: Multiple link-types “hidden” by L3 Flexibility: E.g. multiple Transports, e2e
Transp.
Link Link Link Link Link Link
1
u v x y z w 1 2 2 3 5 5 1 1 3 2 Find “good” paths from source to destination router
2
1 2 3
Dst Egress Link A 1 B 2 C 3 D 1 E 3
A B C D E F
Dst Egress Link F 2 B 1 C 2 D 1 E 1
1 2
3
4
Mark Townsley
4
5
When and where we think we need them for specific purposes
6
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
All problems in computer science can be solved by another level of indirection… …except for the problem of too many levels of indirection
8
9
IP address, Session ID, etc. Control Protocols, mapping algorithms, manual config
Typically involves encapsulation, but encapsulation != tunneling
10
IP address, Session ID, etc. Control Protocols, mapping algorithms, manual config
Typically involves encapsulation, but encapsulation != tunneling
“MAP”
10
IP address, Session ID, etc. Control Protocols, mapping algorithms, manual config
Typically involves encapsulation, but encapsulation != tunneling
“MAP” +
10
IP address, Session ID, etc. Control Protocols, mapping algorithms, manual config
Typically involves encapsulation, but encapsulation != tunneling
“MAP” “ENCAP” +
10
Good: Scalability, “Mobility”, “Traffic Engineering”, etc. Bad: Managing when and where to indirect to (mapping)
Good: Overlays allow transition to new technologies, sunsetting old Bad: Layer violation, introduces emulation artifacts
Good: The “P” in VPNs Bad: Breaks Deep Packet Inspection, Netflow, SPF, etc.
11
12
13
14
15
16
Label Exp S TTL
Label Exp S TTL Label Exp S TTL Label Exp S TTL
MPLS PDU (IP packet, L2-Frame, etc) Data Link (Ethernet, PPP, Sonet, etc..)
16
IPv6 are both still “philosophically” IP
17
IPv4-Only Network IPv4-Only Network IPv4-Only Users
NAT
NAT
IPv6-Only IPv6-Only Users
CE
Dual Stack Network Dual-Stack Users
PE PE
CE
18
IPv4-Only Network IPv4-Only Network IPv4-Only Users
NAT
NAT
IPv6-Only Dual Stack Network IPv6-Only Users
CE
6↔4
Dual Stack Network IPv4 Only Dual-Stack Users Dual-Stack Users IPv6 Only Dual Stack Network Dual Stack Network Dual-Stack Users
PE PE
CE CE CE
19
20
21
1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 1 Ve Versio Version rsion IHL IHL IHL TO TOS TOS S Tota Total len tal length length th Iden Identifica entification ication ion Flags Flags Flags Frag Fragme ragment o ment offse t offset set TTL TTL TTL Pro Protoco Protocol ==
l == 0x2F == 0x2F (GR F (GRE) RE) 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)
Tunnel IP
C R K S s Recur Flags Version Protocol (0x800 for IP) Checksum (O cksum (Optional) Offset (Optional) Key (Opt y (Optional) Sequ Sequence Numb Number (Optional) Routing : uting ::: (Variable riable length, Optional)
GRE
Address Family SRE Offset SRE Length Routing Information (V tion (Variable length) :::
21
22
1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 1 Ve Versio Version rsion IHL IHL IHL TO TOS TOS S Tota Total len tal length length th Iden Identifica entification ication ion Flags Flags Flags Frag Fragme ragment o ment offse t offset set TTL TTL TTL Pro Protoco Protocol ==
l == 0x2F == 0x2F (GR F (GRE) RE) 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)
Tunnel IP MPLS PDU
GRE Label Exp S TTL
MPLS VPN Label
MPLS PDU (IP packet for RFC 2547)
Rec = 0 Flags = 0 Ver = 0 Protocol = 0x8847 22
23
1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 1 Ve Versio Version rsion IHL IHL IHL TO TOS TOS S Tota Total len tal length length th 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)
Tunnel IP MPLS PDU
Label Exp S TTL
MPLS VPN Label
MPLS PDU (IP packet for RFC 2547)
23
24
25
26
27
“The system sending Configure-Request is telling the peer system that it is willing to receive data sent with the enclosed options enabled.”
“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
“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.”
“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
29
30
6rd
30
6rd
L2TP UDP IP
30
30
L2TP
30
L2TP
30
http://www.interpeak.com/files/l2tp.pdf
31
http://www.interpeak.com/files/l2tp.pdf
32
Non-PPP IPv6 Trans Access/ISP decoupling “L2F replacement” Client VPNs “PPTP replacement” Broadband
33
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
connections.
datagrams
and data source authentication to IP datagrams.
key exchange, etc. (not discussed in depth today)
35
Thanks to Steve Friedl for the Graphics!
36
37
Transport Mode Tunnel Mode
38
39
40
41
41
41
But! This still requires an IPsec “ALG” in your NAT!
42
43
44
44
45
45
http://www.cisco.com/image/gif/paws/14370/vpn3k_ipsec_tcp.pdf
46
Good: Scalability, Mobility, etc. Bad: Managing where to indirect to and when (mapping)
Good: Overlays allow transition to new technologies, sunsetting old Bad: Layer violation, introduces emulation artifacts
Good: The “P” in VPNs Bad: Breaks Deep Packet Inspection, Netflow, SPF, etc.
MPLS-TE, Mobile IP, LISP, ILNP, …
6rd, MAP, Pseudowires, L2TP, PPTP
IPsec, MPLS VPNs
47
Need-driven, not a fundamental part of the Internet Architecture VPNs, Emulation, Transition, Mobilty, etc.
Endpoints + Forwarding (MAP + ENCAP), State Sync, etc.
PPP – Link phases, Configuration negotiation L2TP and PPTP - Compulsory vs. Voluntary tunneling 5218 - Was L2TP Successful?
48