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

From: "Bill Storer \(bstorer\)" <[email-masked]>
Date: Fri, 7 Jul 2006 13:11:42 -0700

Thanks JF,

Some responses after yours.

Bill

> -----Original Message-----
> From: JF Tremblay [mailto:[email-masked]] 
> Sent: Friday, July 07, 2006 10:56 AM
> To: Bill Storer (bstorer); [email-masked]
> Subject: Re: draft-ietf-softwire-hs-framework-l2tpv2-00 comments
> 
> 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>
> 
> > 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?
> 
> Agreed, two host addresses would be fine. Let's remove that.
> 
> > 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.
> 
> 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."

Sounds good.  

> 
> > 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?
> 
> 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.

The RFC refers to #64 as Tunnel-Type, which is where I got confused.

> 
> > 7.1.1.  IPv6 Softwires
> ...
> >    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?
> 
> 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.
> 
> > 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.
> 
> 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
> 
Sounds good.  

Bill

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

---

From: JF Tremblay <[email-masked]>
Date: Fri, 07 Jul 2006 16:23:58 -0400

--On Friday, July 07, 2006 1:11 PM -0700 "Bill Storer (bstorer)" 
<[email-masked]> wrote:

>> 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.
>

s/Tunnel-Medium/Tunnel-Type/g
Sorry, this was a typo in the original text.

JF

---

From: Florent Parent <[email-masked]>
Date: Mon, 10 Jul 2006 17:17:25 -0400

Some other comments on draft-ietf-softwire-hs-framework-l2tpv2-00

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.

It is unclear whether LCP echo/reply should be used or not. Since  
L2TP HELLO exchange is used, should LCP echo/reply *not* be used?

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.

1500-1472=28. That accounts for the IPv4 and UDP headers only. You  
need to subtract the L2TP and PPP header length to represent the  
available MTU to IPv6.

Florent

---

From: "Laurent Toutain" <[email-masked]>
Date: Mon, 10 Jul 2006 23:43:52 +0200

> L2TP HELLO exchange is used, should LCP echo/reply *not* be used?

that's a good question, PPP may be more reactive than L2TP, we have to check
if it is true

Laurent

6.2.1.  MTU

-- 
-----------------------
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: Florent Parent <[email-masked]>
Date: Mon, 10 Jul 2006 18:41:05 -0400

> that's a good question, PPP may be more reactive than L2TP, we have  

Taking into account scalability (to the millions), I think we need to  
avoid having 2 levels of keepalive.

Florent