draft-ietf-softwire-hs-framework-l2tpv2-06.txt   draft-ietf-softwire-hs-framework-l2tpv2-07.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: February 16, 2008 Cisco Systems Expires: March 29, 2008 Cisco Systems
B. Stevant, Ed. B. Stevant, Ed.
GET/ENST Bretagne GET/ENST Bretagne
J. Tremblay J. Tremblay
Trellia Networks Trellia Networks
August 15, 2007 September 26, 2007
Softwires Hub & Spoke Deployment Framework with L2TPv2 Softwires Hub & Spoke Deployment Framework with L2TPv2
draft-ietf-softwire-hs-framework-l2tpv2-06 draft-ietf-softwire-hs-framework-l2tpv2-07
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 February 16, 2008. This Internet-Draft will expire on March 29, 2008.
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 10, line 34 skipping to change at page 10, line 34
|------------------>/64 prefix |------------------>/64 prefix
RA RA
|------------------>DNS, etc. |------------------>DNS, etc.
DHCPv6/v4 DHCPv6/v4
Figure 1: Host CPE as Softwire Initiator Figure 1: Host CPE as Softwire Initiator
In this scenario, IPV6CP negotiates IPv6 over PPP which also provides In this scenario, IPV6CP negotiates IPv6 over PPP which also provides
the capability for the ISP to assign the 64-bit Interface-Identifier the capability for the ISP to assign the 64-bit Interface-Identifier
to the host CPE or perform uniqueness validation for the two to the host CPE or perform uniqueness validation for the two
Interface-IDs at the two PPP ends [RFC2472]. After IPv6 over PPP is Interface-IDs at the two PPP ends [RFC5072]. After IPv6 over PPP is
up, Neighbor Discovery runs over the IPv6 over PPP link, and the LNS up, Neighbor Discovery runs over the IPv6 over PPP link, and the LNS
can assign a 64-bit global prefix to the host CPE via Router can assign a 64-bit global prefix to the host CPE via Router
Advertisement (RA) while other configuration options (such as DNS) Advertisement (RA) while other configuration options (such as DNS)
can be conveyed to the host CPE via DHCPv6/v4. can be conveyed to the host CPE via DHCPv6/v4.
3.1.2. Router CPE as Softwire Initiator 3.1.2. Router CPE as Softwire Initiator
The Softwire Initiator (SI) is the router CPE, which is a dual-stack The Softwire Initiator (SI) is the router CPE, which is a dual-stack
device. The IPv4 traffic SHOULD NOT traverse the Softwire. See device. The IPv4 traffic SHOULD NOT traverse the Softwire. See
Figure 2. Figure 2.
skipping to change at page 11, line 39 skipping to change at page 11, line 39
|------->/64 prefix |------->/64 prefix
RA RA
|-------> DNS, etc. |-------> DNS, etc.
DHCPv4/v6 DHCPv4/v6
Figure 2: Router CPE as Softwire Initiator Figure 2: Router CPE as Softwire Initiator
In this scenario, IPV6CP negotiates IPv6 over PPP which also provides In this scenario, IPV6CP negotiates IPv6 over PPP which also provides
the capability for the ISP to assign the 64-bit Interface-Identifier the capability for the ISP to assign the 64-bit Interface-Identifier
to the router CPE or perform uniqueness validation for the two to the router CPE or perform uniqueness validation for the two
Interface-IDs at the two PPP ends [RFC2472]. After IPv6 over PPP is Interface-IDs at the two PPP ends [RFC5072]. After IPv6 over PPP is
up, Neighbor Discovery runs over the IPv6 over PPP link, and the LNS up, Neighbor Discovery runs over the IPv6 over PPP link, and the LNS
can assign a 64-bit global prefix to the router CPE via Router can assign a 64-bit global prefix to the router CPE via Router
Advertisement (RA). DHCPv6 can be used to perform IPv6 Prefix Advertisement (RA). DHCPv6 can be used to perform IPv6 Prefix
Delegation (e.g., delegating a 48-bit prefix to be used within the Delegation (e.g., delegating a 48-bit prefix to be used within the
home network) and convey other configuration options (such as DNS) to home network) and convey other configuration options (such as DNS) to
the router CPE. the router CPE.
3.1.3. Host behind CPE as Softwire Initiator 3.1.3. Host behind CPE as Softwire Initiator
The CPE is IPv4-only. The Softwire Initiator (SI) is a dual-stack The CPE is IPv4-only. The Softwire Initiator (SI) is a dual-stack
skipping to change at page 12, line 34 skipping to change at page 12, line 34
|------------------------------>/64 prefix |------------------------------>/64 prefix
RA RA
|------------------------------>DNS, etc. |------------------------------>DNS, etc.
DHCPv4/v6 DHCPv4/v6
Figure 3: Host behind CPE as Softwire Initiator Figure 3: Host behind CPE as Softwire Initiator
In this scenario, IPV6CP negotiates IPv6 over PPP which also provides In this scenario, IPV6CP negotiates IPv6 over PPP which also provides
the capability for the ISP to assign the 64-bit Interface-Identifier the capability for the ISP to assign the 64-bit Interface-Identifier
to the host or perform uniqueness validation for the two Interface- to the host or perform uniqueness validation for the two Interface-
IDs at the two PPP ends [RFC2472]. After IPv6 over PPP is up, IDs at the two PPP ends [RFC5072]. After IPv6 over PPP is up,
Neighbor Discovery runs over the IPv6 over PPP link, and the LNS can Neighbor Discovery runs over the IPv6 over PPP link, and the LNS can
assign a 64-bit global prefix to the host via Router Advertisement assign a 64-bit global prefix to the host via Router Advertisement
(RA) while other configuration options (such as DNS) can be conveyed (RA) while other configuration options (such as DNS) can be conveyed
to the host via DHCPv6/v4. to the host via DHCPv6/v4.
3.1.4. Router behind CPE as Softwire Initiator 3.1.4. Router behind CPE as Softwire Initiator
The CPE is IPv4-only. The Softwire Initiator (SI) is a dual-stack The CPE is IPv4-only. The Softwire Initiator (SI) is a dual-stack
device (behind the IPv4-only CPE) acting as an IPv6 CPE router inside device (behind the IPv4-only CPE) acting as an IPv6 CPE router inside
the home network. The IPv4 traffic SHOULD NOT traverse the Softwire. the home network. The IPv4 traffic SHOULD NOT traverse the Softwire.
skipping to change at page 13, line 43 skipping to change at page 13, line 43
|----> /64 |----> /64
RA prefix RA prefix
|----> DNS, |----> DNS,
DHCPv4/v6 etc. DHCPv4/v6 etc.
Figure 4: Router behind CPE as Softwire Initiator Figure 4: Router behind CPE as Softwire Initiator
In this scenario, IPV6CP negotiates IPv6 over PPP which also provides In this scenario, IPV6CP negotiates IPv6 over PPP which also provides
the capability for the ISP to assign the 64-bit Interface-Identifier the capability for the ISP to assign the 64-bit Interface-Identifier
to the v4/v6 router or perform uniqueness validation for the two to the v4/v6 router or perform uniqueness validation for the two
Interface-IDs at the two PPP ends [RFC2472]. After IPv6 over PPP is Interface-IDs at the two PPP ends [RFC5072]. After IPv6 over PPP is
up, Neighbor Discovery runs over the IPv6 over PPP link, and the LNS up, Neighbor Discovery runs over the IPv6 over PPP link, and the LNS
can assign a 64-bit global prefix to the v4/v6 router via Router can assign a 64-bit global prefix to the v4/v6 router via Router
Advertisement (RA). DHCPv6 can be used to perform IPv6 Prefix Advertisement (RA). DHCPv6 can be used to perform IPv6 Prefix
Delegation (e.g., delegating a 48-bit prefix to be used within the Delegation (e.g., delegating a 48-bit prefix to be used within the
home network) and convey other configuration options (such as DNS) to home network) and convey other configuration options (such as DNS) to
the v4/v6 router. the v4/v6 router.
3.2. IPv4 over IPv6 Softwire with L2TPv2 3.2. IPv4 over IPv6 Softwire with L2TPv2
The following subsections cover IPv4 connectivity across an IPv6-only The following subsections cover IPv4 connectivity across an IPv6-only
skipping to change at page 19, line 9 skipping to change at page 19, line 9
Information Base" [RFC3371]. Information Base" [RFC3371].
RFC 4087 "IP Tunnel MIB" [RFC4087]. RFC 4087 "IP Tunnel MIB" [RFC4087].
* Both IPv4 and IPv6 transports are supported. * Both IPv4 and IPv6 transports are supported.
4.5. Softwire Payload Related 4.5. Softwire Payload Related
4.5.1. For IPv6 Payloads 4.5.1. For IPv6 Payloads
RFC 2461 "Neighbor Discovery for IP Version 6 (IPv6)" [RFC2461]. RFC 4861 "Neighbor Discovery for IP Version 6 (IPv6)" [RFC4861].
RFC 2472 "IP Version 6 over PPP" [RFC2472].
* See also [I-D.ietf-ipv6-over-ppp-v2]. RFC 5072 "IP Version 6 over PPP" [RFC5072].
RFC 3315 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" RFC 3315 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)"
[RFC3315]. [RFC3315].
RFC 3646 "DNS Configuration options for Dynamic Host Configuration RFC 3646 "DNS Configuration options for Dynamic Host Configuration
Protocol for IPv6 (DHCPv6)" [RFC3646]. Protocol for IPv6 (DHCPv6)" [RFC3646].
4.5.2. For IPv4 Payloads 4.5.2. For IPv4 Payloads
RFC 1332 "The PPP Internet Protocol Control Protocol (IPCP)" RFC 1332 "The PPP Internet Protocol Control Protocol (IPCP)"
skipping to change at page 27, line 11 skipping to change at page 27, line 11
A detailed discussion of Softwires security is contained in A detailed discussion of Softwires security is contained in
[I-D.ietf-softwire-security-requirements]. [I-D.ietf-softwire-security-requirements].
5.2.4. IPCP 5.2.4. IPCP
5.2.4.1. IPV6CP 5.2.4.1. IPV6CP
In the IPv6 over IPv4 scenarios (see Section 3.1), after the In the IPv6 over IPv4 scenarios (see Section 3.1), after the
authentication phase, the Softwire Initiator MUST negotiate IPV6CP as authentication phase, the Softwire Initiator MUST negotiate IPV6CP as
defined in [RFC2472]. IPV6CP provides a way to negotiate a unique defined in [RFC5072]. IPV6CP provides a way to negotiate a unique
64-bit Interface-Identifier to be used for the address 64-bit Interface-Identifier to be used for the address
autoconfiguration at the local end of the link. autoconfiguration at the local end of the link.
5.2.4.2. IPv4CP 5.2.4.2. IPv4CP
In the IPv4 over IPv6 scenarios (see Section 3.2), a Softwire In the IPv4 over IPv6 scenarios (see Section 3.2), a Softwire
Initiator MUST negotiate IPCP [RFC1332]. The SI uses IPCP to obtain Initiator MUST negotiate IPCP [RFC1332]. The SI uses IPCP to obtain
an IPv4 address from the SC. IPCP may also be used to obtain DNS an IPv4 address from the SC. IPCP may also be used to obtain DNS
information as described in [RFC1877]. information as described in [RFC1877].
5.3. Global IPv6 Address Assignement to Endpoints 5.3. Global IPv6 Address Assignement to Endpoints
In several scenarios defined in Section 3, Global IPv6 addresses are In several scenarios defined in Section 3, Global IPv6 addresses are
expected to be allocated to Softwires end points. Since IPV6CP only expected to be allocated to Softwires end points. Since IPV6CP only
provide Link-Local addresses (see [RFC2472]), IPv6 Neighbor Discovery provide Link-Local addresses (see [RFC5072]), IPv6 Neighbor Discovery
[RFC2462] or DHCPv6 [RFC3315] SHOULD be used to configure these [RFC4862] or DHCPv6 [RFC3315] SHOULD be used to configure these
addresses. addresses.
The Softwire Initiator of an IPv6 Softwire MUST send a Router The Softwire Initiator of an IPv6 Softwire MUST send a Router
Solicitation message to the Softwire Concentrator after IPV6CP is Solicitation message to the Softwire Concentrator after IPV6CP is
completed. The Softwire Concentrator MUST answer with a Router completed. The Softwire Concentrator MUST answer with a Router
Advertisement. This message MUST contains the global IPv6 prefix of Advertisement. This message MUST contains the global IPv6 prefix of
the PPP link if Neighbor discovery is used to configure addresses of the PPP link if Neighbor discovery is used to configure addresses of
Softwire end points. Softwire end points.
If DHCPv6 is available for address delegation, the M bits of the If DHCPv6 is available for address delegation, the M bits of the
Router Advertisement SHOULD be set. The Softwire Initiator MUST then Router Advertisement SHOULD be set. The Softwire Initiator MUST then
send a DHCPv6 Request to configure the address of the Softwire send a DHCPv6 Request to configure the address of the Softwire
endpoint. endpoint.
Duplicate Address Detection ([I-D.ietf-ipv6-2461bis]) MUST be Duplicate Address Detection ([RFC4861]) MUST be performed on the
performed on the Softwire in both cases. Softwire in both cases.
5.4. DHCP 5.4. DHCP
The Softwire Initiator MAY use DHCP to get additional information The Softwire Initiator MAY use DHCP to get additional information
such as delegated prefix and DNS servers. If the SI supports DHCP, such as delegated prefix and DNS servers. If the SI supports DHCP,
it SHOULD send a Solicit message to verify if more information is it SHOULD send a Solicit message to verify if more information is
available. available.
When delegating an IPv4 prefix to the SI, the SC SHOULD inject a When delegating an IPv4 prefix to the SI, the SC SHOULD inject a
route for this prefix in the IPv4 routing table in order to forward route for this prefix in the IPv4 routing table in order to forward
skipping to change at page 34, line 33 skipping to change at page 34, line 33
[RFC1994] Simpson, W., "PPP Challenge Handshake Authentication [RFC1994] Simpson, W., "PPP Challenge Handshake Authentication
Protocol (CHAP)", RFC 1994, August 1996. Protocol (CHAP)", RFC 1994, August 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434, IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998. October 1998.
[RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998.
[RFC2472] Haskin, D. and E. Allen, "IP Version 6 over PPP",
RFC 2472, December 1998.
[RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, [RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn,
G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"", G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"",
RFC 2661, August 1999. RFC 2661, August 1999.
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)", "Remote Authentication Dial In User Service (RADIUS)",
RFC 2865, June 2000. RFC 2865, June 2000.
[RFC3162] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6", [RFC3162] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6",
RFC 3162, August 2001. RFC 3162, August 2001.
skipping to change at page 35, line 31 skipping to change at page 35, line 26
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005. Internet Protocol", RFC 4301, December 2005.
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
RFC 4306, December 2005. RFC 4306, December 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.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, September 2007.
[RFC5072] S.Varada, Haskins, D., and E. Allen, "IP Version 6 over
PPP", RFC 5072, September 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-05 (work in progress), draft-ietf-dhc-subnet-alloc-05 (work in progress),
June 2007. 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]
Narten, T., "Neighbor Discovery for IP version 6 (IPv6)",
draft-ietf-ipv6-2461bis-11 (work in progress), March 2007.
[I-D.ietf-ipv6-over-ppp-v2]
Varada, S., "IP Version 6 over PPP",
draft-ietf-ipv6-over-ppp-v2-03 (work in progress),
May 2007.
[I-D.ietf-softwire-security-requirements] [I-D.ietf-softwire-security-requirements]
Yamamoto, S., "Softwire Security Analysis and Yamamoto, S., "Softwire Security Analysis and
Requirements", Requirements",
draft-ietf-softwire-security-requirements-03 (work in draft-ietf-softwire-security-requirements-03 (work in
progress), July 2007. progress), July 2007.
[I-D.stevant-softwire-accounting] [I-D.stevant-softwire-accounting]
Stevant, B., "Accounting on Softwires", Stevant, B., "Accounting on Softwires",
draft-stevant-softwire-accounting-01 (work in progress), draft-stevant-softwire-accounting-01 (work in progress),
October 2006. October 2006.
skipping to change at page 36, line 31 skipping to change at page 36, line 21
the IP Network Control Protocol of the Point-to-Point the IP Network Control Protocol of the Point-to-Point
Protocol", RFC 1473, June 1993. Protocol", RFC 1473, June 1993.
[RFC1877] Cobb, S. and F. Baker, "PPP Internet Protocol Control [RFC1877] Cobb, S. and F. Baker, "PPP Internet Protocol Control
Protocol Extensions for Name Server Addresses", RFC 1877, Protocol Extensions for Name Server Addresses", RFC 1877,
December 1995. December 1995.
[RFC2433] Zorn, G. and S. Cobb, "Microsoft PPP CHAP Extensions", [RFC2433] Zorn, G. and S. Cobb, "Microsoft PPP CHAP Extensions",
RFC 2433, October 1998. RFC 2433, October 1998.
[RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor
Discovery for IP Version 6 (IPv6)", RFC 2461,
December 1998.
[RFC2867] Zorn, G., Aboba, B., and D. Mitton, "RADIUS Accounting [RFC2867] Zorn, G., Aboba, B., and D. Mitton, "RADIUS Accounting
Modifications for Tunnel Protocol Support", RFC 2867, Modifications for Tunnel Protocol Support", RFC 2867,
June 2000. June 2000.
[RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, [RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege,
M., and I. Goyret, "RADIUS Attributes for Tunnel Protocol M., and I. Goyret, "RADIUS Attributes for Tunnel Protocol
Support", RFC 2868, June 2000. Support", RFC 2868, June 2000.
[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network
Address Translator (Traditional NAT)", RFC 3022, Address Translator (Traditional NAT)", RFC 3022,
skipping to change at page 37, line 21 skipping to change at page 37, line 9
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, October 2005. Addresses", RFC 4193, October 2005.
[RFC4293] Routhier, S., "Management Information Base for the [RFC4293] Routhier, S., "Management Information Base for the
Internet Protocol (IP)", RFC 4293, April 2006. Internet Protocol (IP)", RFC 4293, April 2006.
[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.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007.
[RFC4925] Li, X., Dawkins, S., Ward, D., and A. Durand, "Softwire [RFC4925] Li, X., Dawkins, S., Ward, D., and A. Durand, "Softwire
Problem Statement", RFC 4925, July 2007. Problem Statement", RFC 4925, July 2007.
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 -06 and -07:
o Changed RFC numbers: RFC2461 and I-D 2461(bis) to [RFC4861],
RFC2462 to [RFC4862], and RFC2472 and I-D.ietf-ipv6-over-ppp-v2 to
[RFC5072].
Changes between -05 and -06: Changes between -05 and -06:
o Swapped Section 4.1 and Section 4.2. Renamed Section 4.2 to o Swapped Section 4.1 and Section 4.2. Renamed Section 4.2 to
"Securing the Softwire Transport". "Securing the Softwire Transport".
o In Section 5.2.1, added a mention that the MTU should be lower o In Section 5.2.1, added a mention that the MTU should be lower
that 1460 when using IPsec. that 1460 when using IPsec.
o In Section 10, added pointers to [RFC4301] and [RFC4306]. o In Section 10, added pointers to [RFC4301] and [RFC4306].
Changes between -04 and -05: Changes between -04 and -05:
o Replaced "documentation" with "logging purposes" in o Replaced "documentation" with "logging purposes" in
Section 5.1.1.1. Section 5.1.1.1.
o Added suggested values (only as guidance) for Keepalives in o Added suggested values (only as guidance) for Keepalives in
Section 5.1.2. 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], [RFC4861], 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:
"MIB support for L2TPv2 and PPP are documented." "MIB support for L2TPv2 and PPP are documented."
o Fixed some RFC2119 keywords in Section 3.1.1, Section 3.1.2, o Fixed some RFC2119 keywords in Section 3.1.1, Section 3.1.2,
skipping to change at page 40, line 31 skipping to change at page 40, line 28
o Clarifications on PFC and ACFC, remove Figure 13. o Clarifications on PFC and ACFC, remove Figure 13.
o Section 5.2.3: make references to RFCs for PAP, CHAP, etc. o Section 5.2.3: make references to RFCs for PAP, CHAP, etc.
o Rewordings in Section 5.2.4.1 and Section 5.2.4.2. o Rewordings in Section 5.2.4.1 and Section 5.2.4.2.
o Added Informative references to [RFC4623], [RFC1661], [RFC2433], o Added Informative references to [RFC4623], [RFC1661], [RFC2433],
and [RFC3748]. and [RFC3748].
o Renamed the title and added more details on Section 5.3 and IPv6 o Renamed the title and added more details on Section 5.3 and IPv6
ND, including a pointer to [I-D.ietf-ipv6-2461bis]. ND, including a pointer to I-D.ietf-ipv6-2461bis.
o Added text in Section 5.4 about IPv4 PD is non-trivial and non o Added text in Section 5.4 about IPv4 PD is non-trivial and non
commonly done. commonly done.
o Added B. Stevant as Editor. o Added B. Stevant as Editor.
o Clarification in Section 5.2.4.1 and Section 5.2.4.2 regarding the o Clarification in Section 5.2.4.1 and Section 5.2.4.2 regarding the
scope of the MUST (to the specific scenarios). scope of the MUST (to the specific scenarios).
o Removed considerations about reverse DNS from Section 6, agreed on o Removed considerations about reverse DNS from Section 6, agreed on
 End of changes. 21 change blocks. 
38 lines changed or deleted 33 lines changed or added

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