1 / 20

Softwires Hub & Spoke using L2TPv3

Softwires Hub & Spoke using L2TPv3. Bill Storer. L2TPv3 (RFC 3931) Improvements. Supports multiple encapsulations UDP IP (Protocol 115) Supports multiple payload types PPP IP Supports enhanced security Message digest on every control message Lightweight cookie on data messages

rusk
Download Presentation

Softwires Hub & Spoke using L2TPv3

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Softwires Hub & Spoke using L2TPv3 Bill Storer

  2. L2TPv3 (RFC 3931) Improvements • Supports multiple encapsulations • UDP • IP (Protocol 115) • Supports multiple payload types • PPP • IP • Supports enhanced security • Message digest on every control message • Lightweight cookie on data messages • L2TPv3 supports VCCV • Enhanced diagnostic and fault detection

  3. Which improvements should we use? • UDP vs IP encapsulation • UDP MUST be supported • NAT • IP (Protocol 115) MUST be supported • Stated in RFC • PPP vs IP payload • PPP MUST be supported • Easiest to integrate with existing L2TPv2 support • IP SHOULD be supported • Enhanced security • Use of enhanced security is optional • MUST support message digest if requested • MUST support cookie if requested • VCCV • MAY be supported as needed

  4. Use of the IP Pseudowire • Authentication may be provided using tunnel authentication • Host Name AVP is the user name • A shared secret is associated with the SI’s host name on the SC • Host Name and shared secret may be provided to the SI just as the PPP user name and password are provided • Only one user per tunnel, which is standard for H&S • PANA is also an option for Authentication • draft-ietf-pana-pana-12

  5. Use of the IP Pseudowire (cont) • IP address assignment • DHCP for IPv4 • Stateless auto config and/or DHCPv6 for IPv6 • No new AVPs necessary

  6. Use of the PPP Pseudowire • PPP authentication may be used (same as L2TPv2) • Tunnel authentication as in the IP Pseudowire • IPv4 address assignment • IPCP MUST be used for initial address assignment • DHCP MUST be used for prefix delegation • IPv6 address assignment • IPv6CP MUST be used to determine the Interface ID portion of the address • DHCPv6 or stateless autoconfig may be used for the prefix portion of the address • DHCPv6 MUST be used for prefix delegation

  7. L2TPv3 Message Details

  8. SCCRQ Message • MUST AVPs • Host Name • May be used to authenticate end user • May be “Softwires” if no authentication • Router ID • MUST NOT be sent for Softwires • Marked as MUST, but only for LAC-LAC applications. • Pseudowire Capabilities List • IP, PPP, or both • Others • As specified in the draft • MAY AVPs • Control Connection Tie Breaker • Should never be a tie • Others as needed

  9. SCCRP Message • MUST AVPs • Host Name • May be used to authenticate end user • May be “Softwires” if no authentication • Router ID • MUST NOT be sent for Softwires • Marked as MUST, but only for LAC-LAC applications. • Pseudowire Capabilities List • IP, PPP, or both • Others • As specified in the draft • MAY AVPs • As needed

  10. SCCCN and StopCCN Messages • MUST AVPs • As specified in the draft • MAY AVPs • As needed

  11. HELLO Message • We need the HELLO message • Don’t have any other keep alive message for IP Pseudowire • Prefer to use the HELLO instead of the LCP echo for PPP Pseudowire • MUST AVPs • As specified in the draft • MAY AVPs • As specified in the draft

  12. ICRQ Message • MUST AVPs • Pseudowire Type • IP or PPP • Remote End ID • MUST NOT be sent for Softwires • Marked as MUST, but only for LAC-LAC applications. • Circuit Status • New and Active bits set • Others • As specified in the draft

  13. ICRQ Message (cont) • MAY AVPs • Session Tie Breaker • Should be no ties • Data Sequencing • Shouldn’t be necessary • Others • As specified in the draft

  14. ICRP Message • MUST AVPs • Circuit Status • New and Active bits set • Others • As specified in the draft • MAY AVPs • Data Sequencing • Shouldn’t be necessary • Others • As specified in the draft

  15. ICCN Message • MUST AVPs • As specified in the draft • MAY AVPs • Data Sequencing • Shouldn’t be necessary • Others • As specified in the draft

  16. CDN Message • MUST AVPs • As specified in the draft • MAY AVPs • As needed

  17. SLI and WEN Messages • SLI is not relevant to softwires • Change in circuit status disconnects call • No special information needs to be sent after the call is established • WEN is not relevant to softwires • Softwires uses voluntary tunneling

  18. Explicit Ack Message • Necessary if using authentication • MAY AVPs • As specified in the draft

  19. PPP Payload Specifics • draft-ietf-l2tpext-l2tp-ppp-xx.txt • Discusses transport of PPP over L2TPv3 • Forwarding PPP frames • Very similar to L2TPv2 • Address and Control fields are NOT transmitted over the tunnel • Only one of the PPP specific AVPs discussed there has relevance to softwires • Offset Size • Use is optional

  20. IP Payload Specifics • draft-ietf-l2tpext-pwe3-ip-xx.txt • Discusses transport of IP over L2TPv3 • Not very relevant to Softwires • Needed to define the IP payload type

More Related