Subject: [Softwires] draft-ietf-softwire-hs-framework-l2tpv2-00 comments

From: "Bill Storer \(bstorer\)" <[email-masked]>
Date: Wed, 5 Jul 2006 17:39:54 -0700

Hi All,

Thanks for all of the effort on the hs-framework doc.  I've included
part of the doc here with my questions and comments under WFS.

Regards,

Bill

5.  Provisioning Model

   A softwire can provide stable addressing even if the underlying
   addressing scheme changes, by opposition to automatic tunneling.  A
   Softwire Concentrator SHOULD always provide the same address and
   prefix to a reconnecting user.  However, if the goal of the softwire
   service is to provide a temporary address for a roaming user, it MAY
   be provisioned to provide only a temporary address.

   The address and prefix is expected to change when reconnecting to a
   different Softwire Concentrator.  However an organization providing a
   softwire service MAY provide the same address and prefix across
   different Softwire Concentrators at the cost of a more fragmented
   routing table.  The routing fragmentation issue may be limited if the
   prefixes are aggregated in a location topologically close to the SC.
   This would be the case for example if several SCs are put in parallel
   for load-balancing purpose.

5.1.  Link Addresses

5.1.1.  IPv6

   A Softwire Concentrator SHOULD provide globally routable addresses
   and prefixes to Softwire Initiators.  Other types of addresses such
   as Unique Local Addresses [RFC4193] MAY be used to connect to a
   private network with no global connectivity.

   A single /64 SHOULD be reserved for the PPP link.  That /64 MAY be
   part of the prefix delegated to the SI.

5.1.2.  IPv4

   A Softwire Concentrator MAY provide either globally routable or
   private IPv4 addresses.  If private addresses are used, the delegated
   prefix should be in the same address space than the PPP endpoint to
   avoid nested NAT configurations.  A globally routable address is
   preferable, since in most cases, it is expected the CPE device will
   perform the IPv4 NAT function.

   The PPP link for the IPv4 softwire SHOULD be assigned a /30.

WFS Why a /30?  

Storer, et al.          Expires December 18, 2006              [Page 19]

Internet-Draft    Softwires H & S Framework with L2TPv2        June 2006

5.2.  Delegated Prefixes

5.2.1.  IPv6 Prefixes

   Delegated IPv6 prefixes are between /48 and /64 in length.  A CPE
   device receiving a /64 is expected to perform bridging if more than
   one interface is available (wired and wireless for example).

   The length of delegated IPv6 prefixes SHOULD be a multiple of 4.
   Reverse DNS delegation of IPv6 prefixes that are not multiples of 4
   is more complex since more than one record must be inserted in the
   zone file.  In the worst case, up to 8 records have to be entered for
   one prefix if the prefix length is equal to a multiple of 4 plus 1
   (/61 for example).

   Example:

      One NS record is required for the reverse DNS delegation of 2001:
      db8:1:10::/60

         NS 1.0.0.1.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa ns.example.com

      Several (8) NS records are required for the reverse DNS delegation
      of 2001:db8:1:10::/61

         NS 0.1.0.0.1.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa ns.example.com

         NS 1.1.0.0.1.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa ns.example.com

         NS 2.1.0.0.1.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa ns.example.com

         NS 3.1.0.0.1.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa ns.example.com

         NS 4.1.0.0.1.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa ns.example.com

         NS 5.1.0.0.1.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa ns.example.com

         NS 6.1.0.0.1.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa ns.example.com

         NS 7.1.0.0.1.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa ns.example.com

5.2.2.  IPv4 Prefixes

   Delegated IPv4 prefixes should be of the same scope than the assigned
   IPv4 addresses and be routable within that address space.  Prefix
   length is between /8 and /30.  However, the DNS reverse delegation of
   prefixes that are not multiples of 8 may be problematic.  In the
   worst case of a one bit difference, for example a /25, 128 NS records

Storer, et al.          Expires December 18, 2006              [Page 20]

Internet-Draft    Softwires H & S Framework with L2TPv2        June 2006

   must be configured in the reverse zone file.

6.  Softwire Establishment

   A softwire is established in 3 distinct steps (figure 1).  First a
   L2TP tunnel with a single session is established from the SI to the
   SC.  Second a PPP session is established over the L2TP session and
   the SI get an address.  Third the SI optionally gets other
   information through DHCP such as a delegated prefix and DNS servers.

           SC                                 SI
            |                                 |
            |<-------------L2TP-------------->| L2TP
            |                                 |
            |<-------------PPP--------------->| PPP and
            |<-------Neighbor Discovery------>| configuration
            |                                 |
            |<-------------DHCP-------------->| Additional
            |                                 | configuration
            |                                 | (optional)

   Figure 9: Steps for the Establishment of a Softwire

Storer, et al.          Expires December 18, 2006              [Page 21]

Internet-Draft    Softwires H & S Framework with L2TPv2        June 2006

           SC                                 SI
            |                                 |
            |<------------SCCRQ---------------| -
            |-------------SCCRP-------------->| |
            |<------------SCCSN---------------| | L2TP
WFS SCCCN.
            |<------------ICRQ----------------| |
WFS ICRP here.
            |-------------ICCN--------------->| -
            |                                 |
            |<-----Configuration-Request------| -
            |------Configuration-Request----->| | PPP
            |<-------Configuration-Ack--------| | LCP
            |--------Configuration-Ack------->| -
            |                                 |
            |-----------Challenge------------>| - PPP Authentication
            |<----------Response--------------| | (CHAP)
            |------------Success------------->| -
            |                                 |
            |<-----Configuration-Request------| -
            |------Configuration-Request----->| | PPP NCP
            |<-------Configuration-Ack--------| | (IPV6P or IPCP)
WFS IPV6CP.
            |--------Configuration-Ack------->| -
            |                                 |
            |<------Router-Solicitation-------| - Neighbor Discovery
            |-------Router-Advertisement----->| | (IPv6 only)
            |                                 | -
            |                                 |
            |<-----------Solicit--------------| -
            |-----------Advertise------------>| | DHCP
            |<---------- Request--------------| | (Optional)
            |-------------Reply-------------->| -

   Figure 10: Detailed Steps in the Establishment of a Softwire

6.1.  L2TP Tunnel Setup

   L2TPv2 [RFC2661] was initially designed to connect Network Access
   Server (NAS) concentrating traffic from multiple equipments and
   Internet Access Providers (IAP).  In L2TP terminology, an L2TP
   Network Server (LNS) is an equipment concentrating L2TP connection
   coming from L2TP Access Concentrator (LAC) dispatched on the IP
   network.  In the Softwires Hub and Spoke model, LAC will act as the
   Softwires Initiator (SI) and LNS as the Softwires Concentrator (SC).
   SI can be located on the end user equipment, a special gateway
   dedicated to handle IPv6 traffic or directly on the home gateway.

   L2TP packet, in the softwires model MUST be carried over UDP,
   underlying version of the IP protocol may be IPv4 or IPv6, depending
   on the transition scenario deployed.

Storer, et al.          Expires December 18, 2006              [Page 22]

Internet-Draft    Softwires H & S Framework with L2TPv2        June 2006

6.1.1.  Tunnel Establishement

   The following diagram resumes messages exchange and AVP used to
   establish a communication between a SI (LAC) and a SC (LNS).  They
   represent a subset of exchanges defined in [RFC2661] mostly to limit
   implementation complexity on the SI side.  One session per tunnel is
   only needed, since the LAC does not act as a PPP session
   concentrator.  The LAC MUST always establishes the session and no
   outgoing nor analogical calls are specified.  L2TP attributes SHOULD
   NOT be hidden.

Storer, et al.          Expires December 18, 2006              [Page 23]

Internet-Draft    Softwires H & S Framework with L2TPv2        June 2006

   LAC (SI)        LAC (SC)
   ----------      ----------
   SCCRQ ->
   Mandatory AVP
      Message Type
      Protocol Version
      Host Name
      Framing Capabilities
      Assigned Tunnel ID
   Optional AVP:
      Receive Window Size
      Firmware Revision
      Vendor Name
      (Challenge)

                   <- SCCRP
                   Mandatory AVP:
                      Message Type
                      Protocol Version
                      Framing Capabilities
                      Host Name
                      Assigned Tunnel ID
                   Optional AVP:
                      Firmware Revision
                      Vendor Name
                      Receive Window Size
                      (Challenge Response)
                      (Challenge)

   SCCCN ->
   Mandatory AVP:
      Message Type
      (Challenge Response)

                   <- ZLB ACK

   Figure 11: Tunnel Establishement

Storer, et al.          Expires December 18, 2006              [Page 24]

Internet-Draft    Softwires H & S Framework with L2TPv2        June 2006

   LAC (SI)        LAC (SC)
   ----------      ----------
   ICRQ ->
   Mandatory AVP:
      Message Type
      Assigned Session ID
      Call Serial Number

                   <- ICRP
                   Mandatory AVP:
                      Message Type
                      Assigned Session ID

   ICCN ->
   Mandatory AVP:
      Message Type
      (Tx) Connect Speed
      Framing Type

                   <- ZLB ACK

   Figure 12: Session Establishement

   This paragraph specifies specific values for AVP used in the
   Softwires context.

6.1.1.1.  AVPs Required for Sotftwires

   Host Name AVP

      This AVP is mandatory and is present in SCCRQ and SCCRP messages.
      This AVP is for debugging purpose and should not be used to
      authenticate users.

      For the LNS, the hostname COULD be the server name with the fully
      qualified domain.  For the LAC, the name COULD be
      [email-masked].  If name or fully-qualified-
      domain is not configured (since the equipment is in the bootstrap
      phase) this part CAN be left blank.  User-id is the value used to
      authenticate the user.  If user-id is not defined, "Softwires"
      COULD be used.

   Framing Capabilities AVP

      Synchronous bit MUST be set to 1 and Asynchronous bit to 0.  This
      AVP SHOULD be ignored by the receiver.

WFS I still think we should recommend to set both bits here.  They are
really meaningless in this context but being less restrictive should
increase our chance of interoperating.  
Perhaps we should run this by Mark Townsley.

   Framing Type AVP

Storer, et al.          Expires December 18, 2006              [Page 25]

Internet-Draft    Softwires H & S Framework with L2TPv2        June 2006

      Synchronous bit MUST be set to 1and Asynchronous bit to 0.  This
      AVP SHOULD be ignored by the receiver.

   (Tx) Connect Speed

      (Tx) Connect Speed is a mandatory AVP but is meaningful in
      Softwires context.  Value should be left to 0 and ignored by the
      receiver.

   Assigned Tunnel ID, Receive Window Size, Firmware Revision, Vendor
   Name, Call Serial Number, and Assigned Session ID

      As defined in [RFC2661]

6.1.1.2.  AVPs Optional for Sotftwires

   Challenge and Challenge Response AVPs

      Session authentication as defined in [RFC2661] is based on a
      shared secret known by LACs and LNSs, and is not designed to
      authenticate a specific user.  This AVP is not required since
      security enhancement is not guaranteed.  It can be used to limit
      DoS attack but since this secret has to be known by all users
      accessing the service, an attacker can learn it easily.

WFS I'm OK with not requiring tunnel authentication.  However, we should
remove
    the statement that the shared secret has to be known by all users.  
    Both LAC and LNS much have the same secret, however that secret can 
    be different for each LAC as long as each LAC has a different
hostname. 

      While user authentication is typically done at the PPP level,
      tunnel authentication may be helpful in preventing DoS attacks.

6.1.1.3.  AVPs not Required for Softwires

   L2TP specifies numerous AVPs that, while allowed for a given command,
   are irrelevant to a Softwires.  Softwires implementations should not
   send these AVPs.  However, they should ignore them when they are
   received.  This will make it easier to create Softwires applications
   on top of existing L2TP implementations.

6.1.2.  Tunnel Maintenance

   Periodically, SI must transit some message to the SC to maintain
   context in the NAT and can be used to detected tunnel failure (but
   PPP/LCP may be more reactive).  LNS and LAC can generate HELLO
   messages.  As specified in [RFC2661] HELLO messages SHOULD be
   generated if no other messages are sent for a period of time.  The
   value of 60 seconds recommended by [RFC2661] fulfills Softwires
   constraints.

Storer, et al.          Expires December 18, 2006              [Page 26]

Internet-Draft    Softwires H & S Framework with L2TPv2        June 2006

6.1.3.  Tunnel Teardown

   SI and SC can teardown the session and then the tunnel.  No change or
   specific parameter are required compared to [RFC2661].  The SI or the
   SC sends an CDN message, acknowledged by ZLB message.  The initiator
   of the tunnel teardown, MUST immediately after close the tunnel by
   sending a StopCCN message, acknowledged by a ZLB message.

6.2.  PPP Connection

6.2.1.  MTU

   The MTU of the PPP link SHOULD be the link MTU minus the size of the
   IP, UDP and L2TP headers together.  On a link with a MTU equal to
   1500 bytes, this would usually mean a PPP MTU of 1472 bytes.  This
   may vary according to the size of the L2TP header.

   In order to optimize the link efficiency and prevent fragmentation, a
   path MTU discovery algorithm may be used to detect the maximum MTU on
   the path between the SI and the SC.  However path MTU discovery is
   out of scope for this document.

6.2.2.  LCP

   Once the L2TP session is established, the SI initiates the PPP
   connection by sending a LCP Configuration Request message.  The SC
   also sends a LCP Configuration Request containing at least the
   Maximum Receive Unit option and and authentication protocol.  If no
   authentication protocol option is present, the SI considers the
   service as un authenticated (see Section 6.2.3).  Each party answers
   with a Configuration Ack message to finish the link configuration.

   ### Laurent, do you have an example for this section?

6.2.3.  Authentication

   After sending the LCP Configuration Ack, the SC proceeds with the PPP
   authentication phase.  CHAP [RFC1994] authentication MUST be
   supported by both the Softwire Initiator and Softwire Concentrator.
   Optionally, other authentication methods such as PAP, MS-CHAP EAP MAY
   be supported.

   The Softwire Concentrator MAY allow non-authenticated connection.  In
   that case, the SC acts as a gateway for anonymous connections.  This
   approach is better than an open relay implementation since ingress
   filtering is performed on established tunnels (see Section 9).  If
   non-authenticated connections are supported by the SC, enabling this
   function MUST be configurable by the SC administrator.

Storer, et al.          Expires December 18, 2006              [Page 27]

Internet-Draft    Softwires H & S Framework with L2TPv2        June 2006

6.2.4.  IPCP

6.2.4.1.  IPv6CP

   After the authentication phase, the Softwire Initiator MUST send an
   IPV6CP Configuration-Request message [RFC2472] containing an
   Interface Identifier.  The Interface Identifier SHOULD be of the IEEE
   EUI-64 format.  A Configuration-Request message is also sent by the
   SC.  If that message constrains a different Interface Identifier, it
   MUST be accepted through a Configure-Ack message.

6.2.4.2.  IPv4CP

   A Softwire Initiator establishing an IPv4 softwire SHOULD send a
   Configuration-Request with all four octets of the IP-Address
   configuration option set to 0 (see [RFC1332]).  If all four octets of
   the IP-Address option received from the Softwire Concentrator are set
   to 0, the SI MUST request an address through DHCP, otherwise the
   address is accepted.

WFS How about the following for the last sentence above:

"If the Softwire Concentrator does not assign an address to the Softwire
 Initiator, the SI MUST request an address through DHCP."  
I'm suggesting a more generic sentence here because the SC may indicate 
failure to assign  an IP address by sending back an address of 0, or by 
sending a protocol reject in responce to the IPCP CONFREQ.  This may be 
more detail than we want to go into here.  

6.3.  Neighbor Discovery

   The Softwire Initiator of an IPv6 softwire MUST send a Router
   Sollicitation message to the Softwire Concentrator after IPV6CP is
   completed.  The Softwire Concentrator MUST answer with a Router
   Advertisement containing the global IPv6 prefix of the PPP link.

   Duplicate Address Detection (DAD) is redundant in that context and
   doesn't have to be performed.  For that purpose,
   DupAddrDetectTransmits autoconfiguration variable to zero [RFC2472]
   [RFC2462].

   If DHCPv6 is available, the M bits of the Router Advertisement SHOULD
   be set.

6.4.  DHCP

   The Softwire Initiator MAY use DHCP to get additional information
   such as delegated prefix and DNS servers.  If the SI supports DHCP,
   it SHOULD send a Solicit message to verify if more information is
   available.

6.4.1.  DHCPv6

   IF a SI establishing an IPv6 Softwire acts as a router (scenarios
   3.1.2 and 3.1.4) it MUST include the IA_PD option [RFC3633] in the
   DHCPv6 Solicit message [RFC3315] in order to request an IPv6 prefix.

Storer, et al.          Expires December 18, 2006              [Page 28]

Internet-Draft    Softwires H & S Framework with L2TPv2        June 2006

6.4.2.  DHCPv4

   A SI establishing an IPv4 softwire MAY send a DHCP request containing
   the Subnet Allocation option [I-D.ietf-dhc-subnet-alloc].  One
   Subnet-Request suboption MUST be configured with the 'h' bit set to
   '1', as the SI is expected to perform the DHCP server function.  The
   'i' bit of the Subnet-Request suboption should be set to '0' the
   first time a prefix is requested and to '1' on subsequent requests,
   if a prefix has been allocated.  The Prefix length suboption SHOULD
   be 0 by default.  If the SI is configured to support only specific
   prefix lengths, it should specify the longest (smallest) prefix
   length it supports.

   If the SI was previously assigned a prefix from that same SC, it
   SHOULD include the Subnet Information suboption with the prefix it
   was previously assigned.  The 'c' and 's' bits of the suboption
   SHOULD be set to '0'.

7.  AAA

   The Softwire Concentrator is expected to act as a client to a AAA
   server, for example a Radius server.  During the PPP authentication
   phase, the AAA server may return additional information in the form
   of attributes in the Access Accept message.

   The Softwire Concentrator MAY include the Tunnel-Medium and Tunnel-
   Medium-Type attributes [RFC2868] in the Access Request messages to
   provide a hint of the type of softwire being configured.

WFS I couldn't find the Tunnel-Medium attribute in the RFC.  Just the
   Tunnel-Medium-Type.  Am I missing something?

7.1.  Tunnel Endpoints

7.1.1.  IPv6 Softwires

   If the AAA 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 is mentioned [RFC3162], 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 router advertisements.

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

WFS I don't understand why we want to use the Tunnel client/server
Endpoint
   attributes here.  These attributes were originally designed to tell 
   the LAC where to tunnel to/from.  Are these being used by 
   implementations today?  

Storer, et al.          Expires December 18, 2006              [Page 29]

Internet-Draft    Softwires H & S Framework with L2TPv2        June 2006

   router advertisements.

7.1.2.  IPv4 Softwires

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

WFS I think the Framed-IP-Address attribute should be used here.  Same
   comment as above about the Tunnel-Client/Server-Endpoints.

7.2.  Delegated Prefixes

7.2.1.  IPv6 Prefixes

   If the attribute Delegated-IPv6-Prefix [I-D.ietf-radext-delegated-
   prefix] 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 DUID of
   a DHCPv6 request to tunnel it came from and its user.

7.2.2.  IPv4 Prefixes

   ### To complete

8.  Maintenance and Statistics

8.1.  Radius Accounting

   ### To complete

8.2.  MIBs

   See [RFC4293]
   ### To complete

9.  Security Considerations

9.1.  Comparison with softwire security analysis

9.2.  Additional security issues introduced by the integration of the
      different protocols

10.  Implementation status

Storer, et al.          Expires December 18, 2006              [Page 30]

Internet-Draft    Softwires H & S Framework with L2TPv2        June 2006

11.  Open issues

11.1.  Fragmentation and MTU

11.2.  AAA Accounting (other draft)

12.  IANA Considerations

   This document creates no new requirements on IANA namespaces
   [RFC2434].

_______________________________________________
Softwires mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/softwires

---

From: "Laurent Toutain" <[email-masked]>
Date: Fri, 7 Jul 2006 12:13:59 +0200

>    The PPP link for the IPv4 softwire SHOULD be assigned a /30.

I imagine that since  it is a point to point link /30 allows to number both
ends.
Do you think shorter prefixes should be allocated if user wants to have a
network
instead of a host connected to the v4 Internet ?

   Framing Capabilities AVP
> Perhaps we should run this by Mark Townsley.

we can swap SHOULD and MUST

      Synchronous bit SHOULD be set to 1 and Asynchronous bit to 0.  This
      AVP MUST be ignored by the receiver.

>     be different for each LAC as long as each LAC has a different

OK, we can  remove last sentence

      Session authentication as defined in [RFC2661] is based on a
      shared secret known by LACs and LNSs, and is not designed to
      authenticate a specific user.  This AVP is not required since
      security enhancement is not guaranteed.

>    ### Laurent, do you have an example for this section?

I will send you some dump of our traffic to specify options.

-- 
-----------------------
Serveur web du Point6 => http://www.point6.net
Laurent Toutain
ENST Bretagne
tel +33 2 99 12 70 26 - Fax +33 2 99 12 70 30
_______________________________________________
Softwires mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/softwires

---

From: JF Tremblay <[email-masked]>
Date: Fri, 07 Jul 2006 13:56:13 -0400

Hi Bill.
Thanks for your comments. Mine are inline.

--On Wednesday, July 05, 2006 5:39 PM -0700 "Bill Storer (bstorer)" 
<[email-masked]> wrote:

<snip>

>    private IPv4 addresses.  If private addresses are used, the
> delegated    prefix should be in the same address space than the PPP
> endpoint to    avoid nested NAT configurations.  A globally routable
> address is    preferable, since in most cases, it is expected the CPE
> device will    perform the IPv4 NAT function.
>

Agreed, two host addresses would be fine. Let's remove that.

>    configuration option set to 0 (see [RFC1332]).  If all four octets
> of    the IP-Address option received from the Softwire Concentrator
> are set    to 0, the SI MUST request an address through DHCP,
> otherwise the    address is accepted.
>
> "If the Softwire Concentrator does not assign an address to the
> Softwire  Initiator, the SI MUST request an address through DHCP."
> I'm suggesting a more generic sentence here because the SC may
> indicate  failure to assign  an IP address by sending back an address
> of 0, or by  sending a protocol reject in responce to the IPCP
> CONFREQ.  This may be  more detail than we want to go into here.

I'm fine with the new sentence, but writing the two cases when this 
happens seems like a good idea. IMHO, it's not too much details to 
include, as a developer reading this will know exactly how to handle 
this case.

Suggested text:  "If the Softwire Concentrator does not assign an 
address to the Softwire Initiator, the SI MUST request an address 
through DHCP. The SC may indicate a failure to assign an address by 
sending back an address with all octets set to 0 or by sending a 
protocol reject in response to the IPCP CONFREQ."

>    Tunnel-Medium-Type.  Am I missing something?

Tunnel-Medium is defined in section 3.1 of RFC2868, as attribute #64. 
There seems to be a minor glitch in section 6.1 of the RFC, as it 
refers to section 5.1 rather than 3.1 for the definition of the 
attribute.

> 7.1.1.  IPv6 Softwires
...
>    attributes here.  These attributes were originally designed to
> tell     the LAC where to tunnel to/from.  Are these being used by
> implementations today?

Honestly, I don't know how extensively these are used today, but they 
may be used to specify both endpoints of the tunnel, something that 
can't be done with Framed-Interface-Id alone. I would leave it, just in 
case it is useful for some deployments.

>    comment as above about the Tunnel-Client/Server-Endpoints.

The text here should be similar to 7.1.1 and Framed-IP-Address should 
have precedence on the two other attributes. New wording:

   If the Framed-Interface-Id attribute [RFC3162] is present,
   the Softwire Concentrator MUST send it to the Softwire Initiator in
   the Interface Identifier field of its IPCP Configuration Request
   message.

   If the Framed-Interface-Id 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.

JF