draft-ietf-softwire-hs-framework-l2tpv2-04.txt   draft-ietf-softwire-hs-framework-l2tpv2-05.txt 
Softwires Working Group B. Storer Softwires Working Group B. Storer
Internet-Draft C. Pignataro, Ed. Internet-Draft C. Pignataro, Ed.
Intended status: Standards Track M. Dos Santos Intended status: Standards Track M. Dos Santos
Expires: December 10, 2007 Cisco Systems Expires: December 30, 2007 Cisco Systems
B. Stevant, Ed. B. Stevant, Ed.
GET/ENST Bretagne GET/ENST Bretagne
J. Tremblay J. Tremblay
Trellia Networks Trellia Networks
June 8, 2007 June 28, 2007
Softwires Hub & Spoke Deployment Framework with L2TPv2 Softwires Hub & Spoke Deployment Framework with L2TPv2
draft-ietf-softwire-hs-framework-l2tpv2-04 draft-ietf-softwire-hs-framework-l2tpv2-05
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 39 skipping to change at page 1, line 39
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 10, 2007. This Internet-Draft will expire on December 30, 2007.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
This document describes the framework of the Softwire "Hub and Spoke" This document describes the framework of the Softwire "Hub and Spoke"
solution with Layer 2 Tunneling Protocol (L2TPv2), and the solution with Layer 2 Tunneling Protocol (L2TPv2), and the
implementation details specified in this document should be followed implementation details specified in this document should be followed
skipping to change at page 3, line 19 skipping to change at page 3, line 19
5.1.3. Tunnel Teardown . . . . . . . . . . . . . . . . . . . 27 5.1.3. Tunnel Teardown . . . . . . . . . . . . . . . . . . . 27
5.2. PPP Connection . . . . . . . . . . . . . . . . . . . . . . 27 5.2. PPP Connection . . . . . . . . . . . . . . . . . . . . . . 27
5.2.1. MTU . . . . . . . . . . . . . . . . . . . . . . . . . 27 5.2.1. MTU . . . . . . . . . . . . . . . . . . . . . . . . . 27
5.2.2. LCP . . . . . . . . . . . . . . . . . . . . . . . . . 27 5.2.2. LCP . . . . . . . . . . . . . . . . . . . . . . . . . 27
5.2.3. Authentication . . . . . . . . . . . . . . . . . . . . 27 5.2.3. Authentication . . . . . . . . . . . . . . . . . . . . 27
5.2.4. IPCP . . . . . . . . . . . . . . . . . . . . . . . . . 27 5.2.4. IPCP . . . . . . . . . . . . . . . . . . . . . . . . . 27
5.2.4.1. IPV6CP . . . . . . . . . . . . . . . . . . . . . . 27 5.2.4.1. IPV6CP . . . . . . . . . . . . . . . . . . . . . . 27
5.2.4.2. IPv4CP . . . . . . . . . . . . . . . . . . . . . . 28 5.2.4.2. IPv4CP . . . . . . . . . . . . . . . . . . . . . . 28
5.3. Global IPv6 Address Assignement to Endpoints . . . . . . . 28 5.3. Global IPv6 Address Assignement to Endpoints . . . . . . . 28
5.4. DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 5.4. DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
5.4.1. DHCPv6 . . . . . . . . . . . . . . . . . . . . . . . . 28 5.4.1. DHCPv6 . . . . . . . . . . . . . . . . . . . . . . . . 29
5.4.2. DHCPv4 . . . . . . . . . . . . . . . . . . . . . . . . 29 5.4.2. DHCPv4 . . . . . . . . . . . . . . . . . . . . . . . . 29
6. Considerations about the Address Provisioning Model . . . . . 30 6. Considerations about the Address Provisioning Model . . . . . 30
6.1. Softwire Endpoints Addresses . . . . . . . . . . . . . . . 30 6.1. Softwire Endpoints Addresses . . . . . . . . . . . . . . . 30
6.1.1. IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . 30 6.1.1. IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . 30
6.1.2. IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . 30 6.1.2. IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . 30
6.2. Delegated Prefixes . . . . . . . . . . . . . . . . . . . . 30 6.2. Delegated Prefixes . . . . . . . . . . . . . . . . . . . . 30
6.2.1. IPv6 Prefixes . . . . . . . . . . . . . . . . . . . . 30 6.2.1. IPv6 Prefixes . . . . . . . . . . . . . . . . . . . . 30
6.2.2. IPv4 Prefixes . . . . . . . . . . . . . . . . . . . . 31 6.2.2. IPv4 Prefixes . . . . . . . . . . . . . . . . . . . . 31
6.3. Possible scenarios . . . . . . . . . . . . . . . . . . . . 31 6.3. Possible scenarios . . . . . . . . . . . . . . . . . . . . 31
skipping to change at page 25, line 35 skipping to change at page 25, line 35
5.1.1.1. AVPs Required for Softwires 5.1.1.1. AVPs Required for Softwires
This section prescribes specific values for AVPs used in the This section prescribes specific values for AVPs used in the
Softwires context that are Mandatory. Softwires context that are Mandatory.
Host Name AVP Host Name AVP
This AVP is mandatory and is present in SCCRQ and SCCRP messages. This AVP is mandatory and is present in SCCRQ and SCCRP messages.
This AVP may be used to authenticate users, in which case it would This AVP may be used to authenticate users, in which case it would
contain a user identification. If this AVP is not used to contain a user identification. If this AVP is not used to
authenticate users, it may be used for documentation. authenticate users, it may be used for logging purposes.
Framing Capabilities AVP Framing Capabilities AVP
Synchronous bit SHOULD be set to 1 and Asynchronous bit to 1. Synchronous bit SHOULD be set to 1 and Asynchronous bit to 1.
This AVP SHOULD be ignored by the receiver. This AVP SHOULD be ignored by the receiver.
Framing Type AVP Framing Type AVP
Synchronous bit SHOULD be set to 1 and Asynchronous bit to 0. Synchronous bit SHOULD be set to 1 and Asynchronous bit to 0.
This AVP SHOULD be ignored by the receiver. This AVP SHOULD be ignored by the receiver.
skipping to change at page 26, line 44 skipping to change at page 26, line 44
5.1.2. Tunnel Maintenance 5.1.2. Tunnel Maintenance
Periodically, the SI MUST transmit a message to the SC to maintain Periodically, the SI MUST transmit a message to the SC to maintain
NAT/NAPT contexts and detect tunnel failure. The L2TPv2 HELLO NAT/NAPT contexts and detect tunnel failure. The L2TPv2 HELLO
message provides a simple, low overhead method of doing this. message provides a simple, low overhead method of doing this.
The default values specified in [RFC2661] for L2TPv2 HELLO messages The default values specified in [RFC2661] for L2TPv2 HELLO messages
could result in a dead end detection time of 83 seconds. Although could result in a dead end detection time of 83 seconds. Although
these retransmission timers and counters SHOULD be configurable (see these retransmission timers and counters SHOULD be configurable (see
[RFC2661]), these values may not be adapted for all situations, where Section 5.8 of [RFC2661]), these values may not be adapted for all
a quicker dead end detection is required, or where NAT/NAPT context situations, where a quicker dead end detection is required, or where
needs to be refreshed more frequently. In such cases, the SI MAY NAT/NAPT context needs to be refreshed more frequently. In such
use, in combination with L2TPv2 HELLO, LCP ECHO messages (Echo- cases, the SI MAY use, in combination with L2TPv2 HELLO, LCP ECHO
Request and Echo-Reply codes) described in [RFC1661] which timeout messages (Echo-Request and Echo-Reply codes) described in [RFC1661].
could be configured to a lower value. When used, LCP ECHO messages When used, LCP ECHO messages SHOULD have a re-emission timer lower
SHOULD have a re-emission timer lower than the value for L2TPv2 HELLO than the value for L2TPv2 HELLO hello messages. The default value
hello messages. recommended in Section 6.5 of [RFC2661] for the HELLO message
retransmission interval is 60 seconds. When used, a set of suggested
values (included here only for guidance) for the LCP ECHO message
request interval is a default of 30 seconds, a minimum of 10 seconds,
and a maximum of the lesser of the configured L2TPv2 HELLO
retransmisison interval and 60 seconds.
5.1.3. Tunnel Teardown 5.1.3. Tunnel Teardown
Either the SI or SC can teardown the session and tunnel. This is Either the SI or SC can teardown the session and tunnel. This is
done as specified in [RFC2661]. There is no action specific to done as specified in [RFC2661]. There is no action specific to
Softwires in this case. Softwires in this case.
5.2. PPP Connection 5.2. PPP Connection
5.2.1. MTU 5.2.1. MTU
skipping to change at page 41, line 24 skipping to change at page 41, line 24
Stenberg, "UDP Encapsulation of IPsec ESP Packets", Stenberg, "UDP Encapsulation of IPsec ESP Packets",
RFC 3948, January 2005. RFC 3948, January 2005.
[RFC4818] Salowey, J. and R. Droms, "RADIUS Delegated-IPv6-Prefix [RFC4818] Salowey, J. and R. Droms, "RADIUS Delegated-IPv6-Prefix
Attribute", RFC 4818, April 2007. Attribute", RFC 4818, April 2007.
13.2. Informative References 13.2. Informative References
[I-D.ietf-dhc-subnet-alloc] [I-D.ietf-dhc-subnet-alloc]
Johnson, R., "Subnet Allocation Option", Johnson, R., "Subnet Allocation Option",
draft-ietf-dhc-subnet-alloc-04 (work in progress), draft-ietf-dhc-subnet-alloc-05 (work in progress),
October 2006. June 2007.
[I-D.ietf-dhc-v6-relay-radius] [I-D.ietf-dhc-v6-relay-radius]
Lau, W., "DHCPv6 Relay agent RADIUS Attribute Option", Lau, W., "DHCPv6 Relay agent RADIUS Attribute Option",
draft-ietf-dhc-v6-relay-radius-02 (work in progress), draft-ietf-dhc-v6-relay-radius-02 (work in progress),
February 2006. February 2006.
[I-D.ietf-ipv6-2461bis] [I-D.ietf-ipv6-2461bis]
Narten, T., "Neighbor Discovery for IP version 6 (IPv6)", Narten, T., "Neighbor Discovery for IP version 6 (IPv6)",
draft-ietf-ipv6-2461bis-11 (work in progress), March 2007. draft-ietf-ipv6-2461bis-11 (work in progress), March 2007.
skipping to change at page 44, line 11 skipping to change at page 44, line 11
[RFC4623] Malis, A. and M. Townsley, "Pseudowire Emulation Edge-to- [RFC4623] Malis, A. and M. Townsley, "Pseudowire Emulation Edge-to-
Edge (PWE3) Fragmentation and Reassembly", RFC 4623, Edge (PWE3) Fragmentation and Reassembly", RFC 4623,
August 2006. August 2006.
Appendix A. Revision History Appendix A. Revision History
[Note to RFC Editor: please remove this entire appendix, and the [Note to RFC Editor: please remove this entire appendix, and the
corresponding entries in the table of contents, prior to corresponding entries in the table of contents, prior to
publication.] publication.]
Changes between -04 and -05:
o Replaced "documentation" with "logging purposes" in
Section 5.1.1.1.
o Added suggested values (only as guidance) for Keepalives in
Section 5.1.2.
Changes between -03 and -04: Changes between -03 and -04:
o Added missing references to [RFC4087], [RFC2461], and [RFC3646], o Added missing references to [RFC4087], [RFC2461], and [RFC3646],
moved [RFC4623] to Informative. moved [RFC4623] to Informative.
o Rephrasing in Section 6.2.2. Added pointers Section 6.1.2 and o Rephrasing in Section 6.2.2. Added pointers Section 6.1.2 and
Section 6.2.2 in Table 2. Section 6.2.2 in Table 2.
o Added citations (and corresponding references) to [RFC1471] and o Added citations (and corresponding references) to [RFC1471] and
[RFC1473] in Section 4.4, since Section 9.2 explicitly mentions: [RFC1473] in Section 4.4, since Section 9.2 explicitly mentions:
 End of changes. 9 change blocks. 
16 lines changed or deleted 29 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/