Skip to main content

Softwire Hub and Spoke Deployment Framework with Layer Two Tunneling Protocol Version 2 (L2TPv2)
draft-ietf-softwire-hs-framework-l2tpv2-13

Revision differences

Document history

Date Rev. By Action
2012-08-22
13 (System) post-migration administrative database adjustment to the No Objection position for Pasi Eronen
2012-08-22
13 (System) post-migration administrative database adjustment to the No Objection position for Tim Polk
2012-08-22
13 (System) post-migration administrative database adjustment to the No Objection position for Dan Romascanu
2012-08-22
13 (System) post-migration administrative database adjustment to the No Objection position for Russ Housley
2009-05-15
13 Cindy Morgan State Changes to RFC Ed Queue from Approved-announcement sent by Cindy Morgan
2009-05-14
13 (System) IANA Action state changed to No IC from In Progress
2009-05-14
13 (System) IANA Action state changed to In Progress
2009-05-14
13 Amy Vezza IESG state changed to Approved-announcement sent
2009-05-14
13 Amy Vezza IESG has approved the document
2009-05-14
13 Amy Vezza Closed "Approve" ballot
2009-05-14
13 Amy Vezza State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by Amy Vezza
2009-05-14
13 Ralph Droms [Ballot Position Update] New position, Yes, has been recorded by Ralph Droms
2009-04-21
13 Dan Romascanu [Ballot comment]
2009-04-13
13 Dan Romascanu [Ballot Position Update] Position for Dan Romascanu has been changed to No Objection from Discuss by Dan Romascanu
2009-04-13
13 (System) New version available: draft-ietf-softwire-hs-framework-l2tpv2-13.txt
2009-04-07
13 Ralph Droms Responsible AD has been changed to Ralph Droms from Mark Townsley
2009-04-06
13 Dan Romascanu
[Ballot discuss]
Updated DISCUSS, taking out one of the issues, clarifiedin discussions with the editors.


Presently, not all the scenarios described in the document are …
[Ballot discuss]
Updated DISCUSS, taking out one of the issues, clarifiedin discussions with the editors.


Presently, not all the scenarios described in the document are properly supported by AAA.  As a result, the document redefines existing uses of RADIUS standard attributes, as well as suggests implementation of documents that are currently still Internet Drafts.

Section 8 updates several existing RADIUS standards RFCs, including:

* RFC 2868, by defining new interpretations of the Tunnel-Client-Endpoint and Tunnel-Server-Endpoint attributes in situations where addressing attributes are not present. 

* RFC 2865, by defining new interpretations of the Framed-IP-Address and Framed-IP-Netmask attributes.

Is this really appropriate for a framework document?

> 8.1.  Softwire Endpoints

8.1.1.  IPv6 Softwires

  If the RADIUS server includes a Framed-Interface-Id attribute
  [RFC3162], the Softwire Concentrator must send it to the Softwire
  Initiator in the Interface-Identifier field of its IPV6CP
  Configuration Request message.

  If the Framed-IPv6-Prefix attribute [RFC3162] is included, that
  prefix must be used in the router advertisements sent to the SI.  If
  Framed-IPv6-Prefix is not present but Framed-IPv6-Pool is, the SC
  must choose a prefix with that pool to send RAs.

  If none of the attributes above are included but the AAA server
  returns the Tunnel-Client-Endpoint and Tunnel-Server-Endpoint
  attributes [RFC2868] with the correct address family, these must be
  used in the IPV6CP Interface-Identifier and for the Router
  Advertisements.

The above paragraph defines new interpretations of these attributes.

> 8.1.2.  IPv4 Softwires

  If the Framed-IP-Address attribute [RFC2865] is present, the Softwire
  Concentrator must provide that address to the Softwire Initiator
  during IPCP address negotiation.  That is, when the Softwire
  Initiator requests an IP address from the Softwire Concentrator, the
  address provided should be the Framed-IP-Address.

  If the Framed-IP-Address attribute is not present and the Tunnel-
  Client-Endpoint and Tunnel-Server-Endpoint attributes [RFC2868] are
  present and of the correct address family, these should be used in
  the IPCP IP-Address configuration option.

The above paragraph defines new interpretations of these attributes.

> 8.2.  Delegated Prefixes


> 8.2.2.  IPv4 Prefixes

  The combination of the Framed-IP-Address and Framed-IP-Netmask
  attributes [RFC2865] may be used by the Softwire Concentrator to
  delegate an IPv4 prefix to the Softwire Initiator.

The above paragraph defines new interpretations of these attributes.
2009-03-27
13 Tim Polk [Ballot Position Update] Position for Tim Polk has been changed to No Objection from Undefined by Tim Polk
2009-03-27
13 Tim Polk [Ballot Position Update] Position for Tim Polk has been changed to Undefined from Discuss by Tim Polk
2009-03-18
13 Dan Romascanu
RFC 2866, by referencing draft-stevant-softwire-accounting, which redefines the format of the NAS-IP-Address attribute (which only supports
IPv4 addresses; NAS-IPv6-Address is used to contain …
RFC 2866, by referencing draft-stevant-softwire-accounting, which redefines the format of the NAS-IP-Address attribute (which only supports
IPv4 addresses; NAS-IPv6-Address is used to contain IPv6 addresses).

Is this really appropriate for a framework document?

From draft-stevant-software-accounting-01.txt:

  A RADIUS accounting entry, as defined in [RFC2867], also includes the
  NASIPAddress attribute, which gives the IP address of the NAS used as
  the softwire endpoint.  Based on this information, an operator can
  decide if this softwire is based on IPv4 or IPv6.  In the case of
  provider only deploying IPv6 over IPv4 and IPv4 over IPv6 softwires,
  the nature of the traffic reported in the accounting information
  depends of the address family of NASIPAddress (if NASIPAddress is
  IPv4, accounted traffic is IPv6, if NASIPAddress is IPv6, accounted
  traffic is IPv4).  However, this solution requires extra checking
  when building accounting report and obviously does not work in case
  of IPvX over IPvX softwires.
2009-03-18
13 Dan Romascanu
[Ballot discuss]
Presently, not all the scenarios described in the document are properly supported by AAA.  As a result, the document redefines existing uses of …
[Ballot discuss]
Presently, not all the scenarios described in the document are properly supported by AAA.  As a result, the document redefines existing uses of RADIUS standard attributes, as well as suggests implementation of documents that are currently still Internet Drafts.

Section 8 updates several existing RADIUS standards RFCs, including:

* RFC 2868, by defining new interpretations of the Tunnel-Client-Endpoint and Tunnel-Server-Endpoint attributes in situations where addressing attributes are not present. 

* RFC 2865, by defining new interpretations of the Framed-IP-Address and Framed-IP-Netmask attributes.

Is this really appropriate for a framework document?

> 8.1.  Softwire Endpoints

8.1.1.  IPv6 Softwires

  If the RADIUS server includes a Framed-Interface-Id attribute
  [RFC3162], the Softwire Concentrator must send it to the Softwire
  Initiator in the Interface-Identifier field of its IPV6CP
  Configuration Request message.

  If the Framed-IPv6-Prefix attribute [RFC3162] is included, that
  prefix must be used in the router advertisements sent to the SI.  If
  Framed-IPv6-Prefix is not present but Framed-IPv6-Pool is, the SC
  must choose a prefix with that pool to send RAs.

  If none of the attributes above are included but the AAA server
  returns the Tunnel-Client-Endpoint and Tunnel-Server-Endpoint
  attributes [RFC2868] with the correct address family, these must be
  used in the IPV6CP Interface-Identifier and for the Router
  Advertisements.

The above paragraph defines new interpretations of these attributes.

> 8.1.2.  IPv4 Softwires

  If the Framed-IP-Address attribute [RFC2865] is present, the Softwire
  Concentrator must provide that address to the Softwire Initiator
  during IPCP address negotiation.  That is, when the Softwire
  Initiator requests an IP address from the Softwire Concentrator, the
  address provided should be the Framed-IP-Address.

  If the Framed-IP-Address attribute is not present and the Tunnel-
  Client-Endpoint and Tunnel-Server-Endpoint attributes [RFC2868] are
  present and of the correct address family, these should be used in
  the IPCP IP-Address configuration option.

The above paragraph defines new interpretations of these attributes.

> 8.2.  Delegated Prefixes

8.2.1.  IPv6 Prefixes

  If the attribute Delegated-IPv6-Prefix [RFC4818] is present in the
  RADIUS Access-Accept message, it must be used by the Softwire
  Concentrator for the delegation of the IPv6 prefix.  Since the prefix
  delegation is performed by DHCPv6 and the attribute is linked to a
  username, the SC must associate the DHCP Unique Identifier (DUID) of
  a DHCPv6 request to the tunnel it came from and its user.

  Interaction between RADIUS, PPP and DHCPv6 server may follow the
  mechanism proposed in [I-D.ietf-dhc-v6-relay-radius].  In this case,
  during the Softwire authentication phase, PPP collects the RADIUS
  attributes for the user such as Delegated-IPv6-Prefix.  A specific
  DHCPv6 relay is assigned to the Softwire.  The DHCPv6 relay fills in
  these attributes in the Relay agent RADIUS Attribute Option (RRAO)
  DHCPv6 option, before forwarding the DHCPv6 requests to the DHCPv6
  server.

The above paragraph makes what would appear to be a normative reference to an I-D - however this document is listed as informational reference. 

> 8.2.2.  IPv4 Prefixes

  The combination of the Framed-IP-Address and Framed-IP-Netmask
  attributes [RFC2865] may be used by the Softwire Concentrator to
  delegate an IPv4 prefix to the Softwire Initiator.

The above paragraph defines new interpretations of these attributes.
2009-03-18
13 Dan Romascanu [Ballot comment]
2009-03-18
13 Dan Romascanu
[Ballot discuss]
Presently, not all the scenarios described in the document are properly supported by AAA.  As a result, the document redefines existing uses of …
[Ballot discuss]
Presently, not all the scenarios described in the document are properly supported by AAA.  As a result, the document redefines existing uses of RADIUS standard attributes, as well as suggests implementation of documents that are currently still Internet Drafts.

Section 8 updates several existing RADIUS standards RFCs, including:

* RFC 2868, by defining new interpretations of the Tunnel-Client-Endpoint and Tunnel-Server-Endpoint attributes in situations where addressing attributes are not present. 

* RFC 2865, by defining new interpretations of the Framed-IP-Address and Framed-IP-Netmask attributes.

* RFC 2866, by referencing draft-stevant-softwire-accounting, which redefines the format of the NAS-IP-Address attribute (which only supports
IPv4 addresses; NAS-IPv6-Address is used to contain IPv6 addresses).

Is this really appropriate for a framework document?

From draft-stevant-software-accounting-01.txt:

  A RADIUS accounting entry, as defined in [RFC2867], also includes the
  NASIPAddress attribute, which gives the IP address of the NAS used as
  the softwire endpoint.  Based on this information, an operator can
  decide if this softwire is based on IPv4 or IPv6.  In the case of
  provider only deploying IPv6 over IPv4 and IPv4 over IPv6 softwires,
  the nature of the traffic reported in the accounting information
  depends of the address family of NASIPAddress (if NASIPAddress is
  IPv4, accounted traffic is IPv6, if NASIPAddress is IPv6, accounted
  traffic is IPv4).  However, this solution requires extra checking
  when building accounting report and obviously does not work in case
  of IPvX over IPvX softwires.


> 8.1.  Softwire Endpoints

8.1.1.  IPv6 Softwires

  If the RADIUS server includes a Framed-Interface-Id attribute
  [RFC3162], the Softwire Concentrator must send it to the Softwire
  Initiator in the Interface-Identifier field of its IPV6CP
  Configuration Request message.

  If the Framed-IPv6-Prefix attribute [RFC3162] is included, that
  prefix must be used in the router advertisements sent to the SI.  If
  Framed-IPv6-Prefix is not present but Framed-IPv6-Pool is, the SC
  must choose a prefix with that pool to send RAs.

  If none of the attributes above are included but the AAA server
  returns the Tunnel-Client-Endpoint and Tunnel-Server-Endpoint
  attributes [RFC2868] with the correct address family, these must be
  used in the IPV6CP Interface-Identifier and for the Router
  Advertisements.

The above paragraph defines new interpretations of these attributes.

> 8.1.2.  IPv4 Softwires

  If the Framed-IP-Address attribute [RFC2865] is present, the Softwire
  Concentrator must provide that address to the Softwire Initiator
  during IPCP address negotiation.  That is, when the Softwire
  Initiator requests an IP address from the Softwire Concentrator, the
  address provided should be the Framed-IP-Address.

  If the Framed-IP-Address attribute is not present and the Tunnel-
  Client-Endpoint and Tunnel-Server-Endpoint attributes [RFC2868] are
  present and of the correct address family, these should be used in
  the IPCP IP-Address configuration option.

The above paragraph defines new interpretations of these attributes.

> 8.2.  Delegated Prefixes

8.2.1.  IPv6 Prefixes

  If the attribute Delegated-IPv6-Prefix [RFC4818] is present in the
  RADIUS Access-Accept message, it must be used by the Softwire
  Concentrator for the delegation of the IPv6 prefix.  Since the prefix
  delegation is performed by DHCPv6 and the attribute is linked to a
  username, the SC must associate the DHCP Unique Identifier (DUID) of
  a DHCPv6 request to the tunnel it came from and its user.

  Interaction between RADIUS, PPP and DHCPv6 server may follow the
  mechanism proposed in [I-D.ietf-dhc-v6-relay-radius].  In this case,
  during the Softwire authentication phase, PPP collects the RADIUS
  attributes for the user such as Delegated-IPv6-Prefix.  A specific
  DHCPv6 relay is assigned to the Softwire.  The DHCPv6 relay fills in
  these attributes in the Relay agent RADIUS Attribute Option (RRAO)
  DHCPv6 option, before forwarding the DHCPv6 requests to the DHCPv6
  server.

The above paragraph makes what would appear to be a normative reference to an I-D - however this document is listed as informational reference. 

> 8.2.2.  IPv4 Prefixes

  The combination of the Framed-IP-Address and Framed-IP-Netmask
  attributes [RFC2865] may be used by the Softwire Concentrator to
  delegate an IPv4 prefix to the Softwire Initiator.

The above paragraph defines new interpretations of these attributes.
2009-03-12
13 Pasi Eronen [Ballot Position Update] Position for Pasi Eronen has been changed to No Objection from Discuss by Pasi Eronen
2009-03-09
13 Russ Housley [Ballot Position Update] Position for Russ Housley has been changed to No Objection from Discuss by Russ Housley
2009-03-08
12 (System) New version available: draft-ietf-softwire-hs-framework-l2tpv2-12.txt
2009-02-10
13 Pasi Eronen
[Ballot discuss]
[updated for version -11]

I have reviewed draft-ietf-softwire-hs-framework-l2tpv2-11, and
found it surprisingly easy to understand, and very clearly written.
I have a …
[Ballot discuss]
[updated for version -11]

I have reviewed draft-ietf-softwire-hs-framework-l2tpv2-11, and
found it surprisingly easy to understand, and very clearly written.
I have a couple of (mostly minor) concerns that I'd like to discuss
before recommending approval of the document:

- Figures 9 and 10 should also show the IPsec-related steps (marked
as "Optional").

- The details of how RFC43xx IPsec is used to protect L2TP are in the
softwire-security-requirements draft -- that probably should be a
normative reference? (I'm assuming the intent is that the
security-requirements draft meets the "For IPsec, default profiles
must be defined" requirement from RFC 4925).
2009-02-09
13 (System) Sub state has been changed to AD Follow up from New Id Needed
2009-02-09
11 (System) New version available: draft-ietf-softwire-hs-framework-l2tpv2-11.txt
2009-01-16
13 (System) Removed from agenda for telechat - 2009-01-15
2009-01-15
13 Cindy Morgan State Changes to IESG Evaluation::Revised ID Needed from Waiting for AD Go-Ahead by Cindy Morgan
2009-01-15
13 (System) [Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko by IESG Secretary
2009-01-15
13 Jari Arkko
[Ballot comment]
> If Framed-IPv6-Prefix is not present but Framed-IPv6-Pool is, the SC
> must choose a prefix with that pool to send RAs.

from …
[Ballot comment]
> If Framed-IPv6-Prefix is not present but Framed-IPv6-Pool is, the SC
> must choose a prefix with that pool to send RAs.

from that pool?
2009-01-15
13 David Ward [Ballot Position Update] New position, Recuse, has been recorded by David Ward
2009-01-15
13 Ross Callon [Ballot Position Update] New position, No Objection, has been recorded by Ross Callon
2009-01-15
13 Tim Polk
[Ballot discuss]
This is a discuss- discuss.  To be clear, I am not asking for any changes to the document
at this time.  I would …
[Ballot discuss]
This is a discuss- discuss.  To be clear, I am not asking for any changes to the document
at this time.  I would like to discuss the following issue to see if any change is appropriate.

The security considerations section begins with:

  A detailed discussion of Softwire security is contained in
  [I-D.ietf-softwire-security-requirements].

This is a very useful reference, with nearly 12 pages devoted to the "Hubs and Spokes
Security Guidelines".  This justifies the relatively brief nature of the remaining security
considerations text.

However,  [I-D.ietf-softwire-security-requirements] expired in August 2008.  Without
[I-D.ietf-softwire-security-requirements], the security considerations in this document
are clearly inadequate.  What is the prognosis for [I-D.ietf-softwire-security-requirements]?
That is how long before it will be ready for an IETF Last Call?

I am wondering whether some of the most important points from
[I-D.ietf-softwire-security-requirements] need to be replicated here, or if others feel
that would be overkill...
2009-01-15
13 Tim Polk [Ballot Position Update] New position, Discuss, has been recorded by Tim Polk
2009-01-15
13 Jon Peterson [Ballot Position Update] New position, No Objection, has been recorded by Jon Peterson
2009-01-15
13 Pasi Eronen
[Ballot discuss]
I have reviewed draft-ietf-softwire-hs-framework-l2tpv2-10, and
found it surprisingly easy to understand, and very clearly written.
I have a couple of (mostly minor) …
[Ballot discuss]
I have reviewed draft-ietf-softwire-hs-framework-l2tpv2-10, and
found it surprisingly easy to understand, and very clearly written.
I have a couple of (mostly minor) concerns that I'd like to discuss
before recommending approval of the document:

- L2TP runs over UDP in a rather strange way, and the SCCRP message
(reply from SC to SI) can come from different IP address and port than
where the SCCRQ (1st message from SI to SC) was sent to.  This
obviously doesn't work with NATs that do "Address-Dependent Filtering"
or "Address and Port-Dependent Filtering" (in RFC 4787 terminology).
Should this document say something about the situation? Or even
mandate that the addresses/ports in SCCRP must be the addresses/ports
in SCCRQ reversed? (This issue is mentioned in the security
requirements draft when talking about IPsec, as it complicates IPsec
interaction -- but it applies even when not using IPsec).

- Figures 9 and 10 should also show the IPsec-related steps (marked
as "Optional").

- The details of how RFC43xx IPsec is used to protect L2TP are in the
softwire-security-requirements draft -- that probably should be a
normative reference? (I'm assuming the intent is that the
security-requirements draft meets the "For IPsec, default profiles
must be defined" requirement from RFC 4925).
2009-01-15
13 Pasi Eronen [Ballot Position Update] New position, Discuss, has been recorded by Pasi Eronen
2009-01-15
13 Magnus Westerlund [Ballot Position Update] New position, No Objection, has been recorded by Magnus Westerlund
2009-01-15
13 Dan Romascanu
[Ballot comment]
1. 4.3.  Authentication Authorization Accounting

  RFC 2865  "Remote Authentication Dial In User Service (RADIUS)"
              …
[Ballot comment]
1. 4.3.  Authentication Authorization Accounting

  RFC 2865  "Remote Authentication Dial In User Service (RADIUS)"
              [RFC2865].

Updated by RFC2868, RFC3575, RFC5080.

2. Please avoid using the acronym OAM for Operations and Management. OAM stands for too many things that are close but not the same, and we intent to start recommending that the acronyms are used in the IETF in a consistent manner. Section 2.7 is OK, just get rid of the acronyms.
2009-01-15
13 Dan Romascanu
[Ballot comment]
4.3.  Authentication Authorization Accounting

  RFC 2865  "Remote Authentication Dial In User Service (RADIUS)"
              [ …
[Ballot comment]
4.3.  Authentication Authorization Accounting

  RFC 2865  "Remote Authentication Dial In User Service (RADIUS)"
              [RFC2865].

Updated by RFC2868, RFC3575, RFC5080.
2009-01-15
13 Dan Romascanu
[Ballot discuss]
1. It is not clear what is the scope of section 4 - Standardization Status. Are all the RFCs listed in this section …
[Ballot discuss]
1. It is not clear what is the scope of section 4 - Standardization Status. Are all the RFCs listed in this section required for the interoperability and correct operation of Softwire implementations? In this case I would expect this to be clearly mentioned and that all references belong to the Norative References section. Some are currently listed as Informative.

2. Section 4.3 makes reference to two RFCs (1471, 1473) that include MIB documents written in SMIv1. The use of SMIv1 is allowed under certain conditions - the principal from a syntactic point of view being that the module translates easily in SMIv2 which is conditioned by the fact that they do not include deprecated SYNTAX elements like Opaque or IPAddress. Were these aspects checked wrt. to RFC 1471 and RFC 1473

Also related to the same two RFCs - the informational model described there refers to a version of PPP which was sinced updated by RFC 1548 and then by RFC 1661. Is this information model still valid?

3. Presently, not all the scenarios described in the document are properly supported by AAA.  As a result, the document redefines existing uses of RADIUS standard attributes, as well as suggests implementation of documents that are currently still Internet Drafts.

Section 8 updates several existing RADIUS standards RFCs, including:

* RFC 2868, by defining new interpretations of the Tunnel-Client-Endpoint and Tunnel-Server-Endpoint attributes in situations where addressing attributes are not present. 

* RFC 2865, by defining new interpretations of the Framed-IP-Address and Framed-IP-Netmask attributes.

* RFC 2866, by referencing draft-stevant-softwire-accounting, which redefines the format of the NAS-IP-Address attribute (which only supports
IPv4 addresses; NAS-IPv6-Address is used to contain IPv6 addresses).

Is this really appropriate for a framework document?

From draft-stevant-software-accounting-01.txt:

  A RADIUS accounting entry, as defined in [RFC2867], also includes the
  NASIPAddress attribute, which gives the IP address of the NAS used as
  the softwire endpoint.  Based on this information, an operator can
  decide if this softwire is based on IPv4 or IPv6.  In the case of
  provider only deploying IPv6 over IPv4 and IPv4 over IPv6 softwires,
  the nature of the traffic reported in the accounting information
  depends of the address family of NASIPAddress (if NASIPAddress is
  IPv4, accounted traffic is IPv6, if NASIPAddress is IPv6, accounted
  traffic is IPv4).  However, this solution requires extra checking
  when building accounting report and obviously does not work in case
  of IPvX over IPvX softwires.


> 8.1.  Softwire Endpoints

8.1.1.  IPv6 Softwires

  If the RADIUS server includes a Framed-Interface-Id attribute
  [RFC3162], the Softwire Concentrator must send it to the Softwire
  Initiator in the Interface-Identifier field of its IPV6CP
  Configuration Request message.

  If the Framed-IPv6-Prefix attribute [RFC3162] is included, that
  prefix must be used in the router advertisements sent to the SI.  If
  Framed-IPv6-Prefix is not present but Framed-IPv6-Pool is, the SC
  must choose a prefix with that pool to send RAs.

  If none of the attributes above are included but the AAA server
  returns the Tunnel-Client-Endpoint and Tunnel-Server-Endpoint
  attributes [RFC2868] with the correct address family, these must be
  used in the IPV6CP Interface-Identifier and for the Router
  Advertisements.

The above paragraph defines new interpretations of these attributes.

> 8.1.2.  IPv4 Softwires

  If the Framed-IP-Address attribute [RFC2865] is present, the Softwire
  Concentrator must provide that address to the Softwire Initiator
  during IPCP address negotiation.  That is, when the Softwire
  Initiator requests an IP address from the Softwire Concentrator, the
  address provided should be the Framed-IP-Address.

  If the Framed-IP-Address attribute is not present and the Tunnel-
  Client-Endpoint and Tunnel-Server-Endpoint attributes [RFC2868] are
  present and of the correct address family, these should be used in
  the IPCP IP-Address configuration option.

The above paragraph defines new interpretations of these attributes.

> 8.2.  Delegated Prefixes

8.2.1.  IPv6 Prefixes

  If the attribute Delegated-IPv6-Prefix [RFC4818] is present in the
  RADIUS Access-Accept message, it must be used by the Softwire
  Concentrator for the delegation of the IPv6 prefix.  Since the prefix
  delegation is performed by DHCPv6 and the attribute is linked to a
  username, the SC must associate the DHCP Unique Identifier (DUID) of
  a DHCPv6 request to the tunnel it came from and its user.

  Interaction between RADIUS, PPP and DHCPv6 server may follow the
  mechanism proposed in [I-D.ietf-dhc-v6-relay-radius].  In this case,
  during the Softwire authentication phase, PPP collects the RADIUS
  attributes for the user such as Delegated-IPv6-Prefix.  A specific
  DHCPv6 relay is assigned to the Softwire.  The DHCPv6 relay fills in
  these attributes in the Relay agent RADIUS Attribute Option (RRAO)
  DHCPv6 option, before forwarding the DHCPv6 requests to the DHCPv6
  server.

The above paragraph makes what would appear to be a normative reference to an I-D - however this document is listed as informational reference. 

> 8.2.2.  IPv4 Prefixes

  The combination of the Framed-IP-Address and Framed-IP-Netmask
  attributes [RFC2865] may be used by the Softwire Concentrator to
  delegate an IPv4 prefix to the Softwire Initiator.

The above paragraph defines new interpretations of these attributes.
2009-01-15
13 Dan Romascanu [Ballot Position Update] New position, Discuss, has been recorded by Dan Romascanu
2009-01-14
13 Lars Eggert [Ballot Position Update] New position, No Objection, has been recorded by Lars Eggert
2009-01-14
13 Lars Eggert
[Ballot comment]
Very clear document. Two minor comments:

Section 1., paragraph 1:
>    The Softwires Working Group has selected Layer Two Tunneling Protocol
>  …
[Ballot comment]
Very clear document. Two minor comments:

Section 1., paragraph 1:
>    The Softwires Working Group has selected Layer Two Tunneling Protocol
>    version 2 (L2TPv2) as the phase 1 protocol to be deployed in the
>    Softwire "Hubs and Spokes" solution space.  This document describes
>    the framework for the L2TPv2 "Hubs and Spokes" solution, and the
>    implementation details specified in this document should be followed
>    to achieve interoperability among different vendor implementations.

  Referring to WGs and their decision process in RFCs isn't terribly
  useful, because WGs are ephemeral. I'd suggest to rephrase this to
  talk about the technology itself.


Section 4., paragraph 0:
> 4.  Standardization Status
>
>    This section groups various Internet standards documents and other
>    publications used in Softwires.

  I don't understand the purpose of this section. Is this supposed to be
  a reading list of related work, provided for the convenience of
  implementors? If so, the section title is confusing.
2009-01-14
13 Cullen Jennings [Ballot Position Update] New position, No Objection, has been recorded by Cullen Jennings
2009-01-14
13 Chris Newman [Ballot Position Update] New position, No Objection, has been recorded by Chris Newman
2009-01-14
13 Ron Bonica [Ballot Position Update] New position, No Objection, has been recorded by Ron Bonica
2009-01-12
13 Russ Housley
[Ballot discuss]
The email thread discussing the Last Call comments raised by
  David Black in his Gen-ART Review indicate that a draft -11 will …
[Ballot discuss]
The email thread discussing the Last Call comments raised by
  David Black in his Gen-ART Review indicate that a draft -11 will
  get needed to resolve the comments.  That revised draft has not
  been posted yet.
2009-01-12
13 Russ Housley [Ballot Position Update] New position, Discuss, has been recorded by Russ Housley
2009-01-12
13 Mark Townsley Placed on agenda for telechat - 2009-01-15 by Mark Townsley
2008-12-15
13 (System) State has been changed to Waiting for AD Go-Ahead from In Last Call by system
2008-12-11
13 Amanda Baber IANA Last Call comments:

As described in the IANA Considerations section, we understand
this document to have NO IANA Actions.
2008-12-06
13 Samuel Weiler Request for Last Call review by SECDIR is assigned to Larry Zhu
2008-12-06
13 Samuel Weiler Request for Last Call review by SECDIR is assigned to Larry Zhu
2008-12-01
13 Amy Vezza Last call sent
2008-12-01
13 Amy Vezza State Changes to In Last Call from Last Call Requested by Amy Vezza
2008-11-27
13 Mark Townsley [Ballot Position Update] New position, Yes, has been recorded for Mark Townsley
2008-11-27
13 Mark Townsley Ballot has been issued by Mark Townsley
2008-11-27
13 Mark Townsley Created "Approve" ballot
2008-11-27
13 Mark Townsley State Changes to Last Call Requested from AD Evaluation by Mark Townsley
2008-11-27
13 Mark Townsley Last Call was requested by Mark Townsley
2008-11-27
13 (System) Ballot writeup text was added
2008-11-27
13 (System) Last call text was added
2008-11-27
13 (System) Ballot approval text was added
2008-11-13
13 Mark Townsley State Changes to AD Evaluation from Publication Requested by Mark Townsley
2008-11-03
13 Cindy Morgan
PROTO questionnaire for: draft-ietf-softwire-hs-framework-l2tpv2-10
prepared by: Alain Durand Alain_Durand@cable.comcast.com

  1.a) Have the chairs personally reviewed this version of the Internet
        …
PROTO questionnaire for: draft-ietf-softwire-hs-framework-l2tpv2-10
prepared by: Alain Durand Alain_Durand@cable.comcast.com

  1.a) Have the chairs personally reviewed this version of the Internet
        Draft (ID), and in particular, do they believe this ID is ready
        to forward to the IESG for publication?  Which chair is the WG
        Chair Shepherd for this document?

Alain Durand

  1.c) Do you have concerns that the document needs more review from a
        particular (broader) perspective (e.g., security, operational
        complexity, someone familiar with AAA, internationalization,
        XML, etc.)?

No.

  1.d) Do you have any specific concerns/issues with this document that
        you believe the ADs and/or IESG should be aware of?  For
        example, perhaps you are uncomfortable with certain parts of the
        document, or have concerns whether there really is a need for
        it.  In any event, if your issues have been discussed in the WG
        and the WG has indicated it that it still wishes to advance the
        document, detail those concerns in the write-up.

No.

  1.e) How solid is the WG consensus behind this document?  Does it
        represent the strong concurrence of a few individuals, with
        others being silent, or does the WG as a whole understand and
        agree with it?

There is strong WG consensus behind this document and no one that has
expressed concerns about its progression. 

  1.f) Has anyone threatened an appeal or otherwise indicated extreme
        discontent?  If so, please summarise the areas of conflict in
        separate email to the Responsible Area Director.  (It should be
        separate email because this questionnaire will be entered into
        the tracker).
No.

  1.g) Have the chairs verified that the document checks out against
        all the ID nits? (see http://www.ietf.org/ID-Checklist.html
).
        Boilerplate checks are not enough; this check needs to be
        thorough.

Yes.

  1.h) Has the document split its references into normative and
        informative?  Are there normative references to IDs, where the
        IDs are not also ready for advancement or are otherwise in an
        unclear state?  The RFC Editor will not publish an RFC with
        normative references to IDs (will delay the publication until
        all such IDs are also ready for RFC publicatioin).  If the
        normative references are behind, what is the strategy for their
        completion?  On a related matter, are there normative references
        that are downward references, as described in BCP 97, RFC 3967
        RFC 3967 [RFC3967]?  Listing these supports the Area Director in
        the Last Call downref procedure specified in RFC 3967.

The references are split into normative and informative.


Technical Summary

This document describes the framework of the Softwire "Hub and Spoke"
solution with the Layer 2 Tunneling Protocol version 2 (L2TPv2). The
implementation details specified in this document should be followed
to achieve interoperability among different vendor implementations.


Working Group Summary

  The SOFTWIRE WG supports the development and advancement of this
document. 
 

         

Protocol Quality

  This document was thoroughly reviewed by WG chairs and WG members, 
  including those with expertise in IPv4 to IPv6 transitions and
  interworking. 

  Alain Durand is the WG chair shepherd. Mark Townsley is the responsible
Area Director.
2008-11-03
13 Cindy Morgan Draft Added by Cindy Morgan in state Publication Requested
2008-10-29
10 (System) New version available: draft-ietf-softwire-hs-framework-l2tpv2-10.txt
2008-07-10
09 (System) New version available: draft-ietf-softwire-hs-framework-l2tpv2-09.txt
2008-01-29
08 (System) New version available: draft-ietf-softwire-hs-framework-l2tpv2-08.txt
2007-09-27
07 (System) New version available: draft-ietf-softwire-hs-framework-l2tpv2-07.txt
2007-08-17
06 (System) New version available: draft-ietf-softwire-hs-framework-l2tpv2-06.txt
2007-06-29
05 (System) New version available: draft-ietf-softwire-hs-framework-l2tpv2-05.txt
2007-06-11
04 (System) New version available: draft-ietf-softwire-hs-framework-l2tpv2-04.txt
2007-02-15
03 (System) New version available: draft-ietf-softwire-hs-framework-l2tpv2-03.txt
2006-11-20
02 (System) New version available: draft-ietf-softwire-hs-framework-l2tpv2-02.txt
2006-08-29
01 (System) New version available: draft-ietf-softwire-hs-framework-l2tpv2-01.txt
2006-06-20
00 (System) New version available: draft-ietf-softwire-hs-framework-l2tpv2-00.txt