Subject: Re: [pcp] New Version Notification for draft-vinapamula-softwire-dslite-prefix-binding-00.txt

From: Suresh Kumar Vinapamula Venkata <[email-masked]>
Date: Wed, 7 Aug 2013 00:20:42 +0000

Dear All, 

Please refer to the issue#4 discussed in the document
http://tools.ietf.org/agenda/87/slides/slides-87-pcp-14.pdf (slide 6).
This is further discussed in the below draft.

Please review and comment.

-Suresh

>
>On 7/29/13 10:27 AM, "[email-masked]" <[email-masked]>
>wrote:
>
>>
>>A new version of I-D,
>>draft-vinapamula-softwire-dslite-prefix-binding-00.txt
>>has been successfully submitted by Suresh Vinapamula and posted to the
>>IETF repository.
>>
>>Filename:	 draft-vinapamula-softwire-dslite-prefix-binding
>>Revision:	 00
>>Title:		 Recommendation for Prefix Binding in the Softwire DS-Lite
>>Context
>>Creation date:	 2013-07-29
>>Group:		 Individual Submission
>>Number of pages: 5
>>URL:             
>>http://www.ietf.org/internet-drafts/draft-vinapamula-softwire-dslite-pref
>>i
>>x-binding-00.txt
>>Status:          
>>http://datatracker.ietf.org/doc/draft-vinapamula-softwire-dslite-prefix-b
>>i
>>nding
>>Htmlized:        
>>http://tools.ietf.org/html/draft-vinapamula-softwire-dslite-prefix-bindin
>>g
>>-00
>>
>>
>>Abstract:
>>   This document describes possible issues induced by the change of the
>>   B4 IPv6 address and sketches a set of recommendations.
>>
>>                 
>>        
>>
>>
>>Please note that it may take a couple of minutes from the time of
>>submission
>>until the htmlized version and diff are available at tools.ietf.org.
>>
>>The IETF Secretariat
>>
>>
>>
>

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Mon, 12 Aug 2013 05:35:12 +0000

Hi Suresh,

Interesting problem. 

Comments:

[1] Any specific reason for mentioning EIM, EIF in section 3 ?

I mean PCP server always show the behavior of EIM, EIF.

[2] Step 2 in section 4;

I think SP already track the number of flows, bandwidth utilization, congestion caused by the subscriber etc using architecture like Policy Charging and control (PCC). 

clarify why any new policy changes are required to track subscribers because of DS-lite ?

[3] The other way to solve the problem could be store B4 address in stable storage to handle router reload/crashes etc

[4] 
a) For CPE WAN IPv6 prefix change - would there be a "make before break" scenario for prefix re-numbering ?
b) Step 4 - How different is this problem when compared with pure-IPv6 only devices ?

[5]

Provide more details on why mappings cannot be re-used with the IPv6 address change (but with no prefix change) and the need to clear mappings.
What is the problem in associating existing IPv4 mappings with a new IPv6 address derived from the same prefix ?

[6] Step 6 in Section 4 - clarify what do mean by "clear all resources in use" ? (Are you referring to resetting the TCP connections ?)

[7] Include reference to security considerations given in http://tools.ietf.org/html/draft-ietf-pcp-dslite-00
    clarify what you mean by "active softwires per subscriber" in step 1 of section 4 and default value of 1 ?
    clarify what you mean by "stable prefix" ?

Cheers,
-Tiru.

> -----Original Message-----
> From: Suresh Kumar Vinapamula Venkata [mailto:[email-masked]]
> Sent: Wednesday, August 07, 2013 5:51 AM
> To: [email-masked]
> Subject: Re: [pcp] New Version Notification for draft-vinapamula-softwire-
> dslite-prefix-binding-00.txt
> 
> Dear All,
>

---

From: <[email-masked]>
Date: Mon, 12 Aug 2013 08:56:21 +0200

Hi Tiru,

Please see inline.

Cheers,
Med

>-----Message d'origine-----
>De : [email-masked] [mailto:[email-masked]] De la part de
>Tirumaleswar Reddy (tireddy)
>Envoyé : lundi 12 août 2013 07:35
>À : Suresh Kumar Vinapamula Venkata; [email-masked]
>Objet : Re: [pcp] New Version Notification for draft-vinapamula-softwire-

[Med] That text applies for all mapping types maintained by the AFTR. The statement is not specific to PCP.

>
>[2] Step 2 in section 4;
>
>I think SP already track the number of flows, bandwidth utilization,
>congestion caused by the subscriber etc using architecture like Policy
>Charging and control (PCC).
>

[Med] The point of that step is to explicitly require policies to be enforced per subscriber and not per softwire. In order to avoid explicitly configuring IPv6 prefixes, the text suggest to configure the length of the prefix assigned to subscribers in that domain(e.g., 56 or 64). Doing so, would allow to include stale mappings in the quota in the event a new IPv6 address (from the same prefix) is assigned to the B4 element.  

>
>[3] The other way to solve the problem could be store B4 address in stable
>storage to handle router reload/crashes etc

[Med] This is a constraint on the B4 side. There some contexts which requires that address to change for some reasons (e.g., avoid receiving unsolicited traffic). The document explains how the service is not interrupted: migrate state to the new B4 IPv6 address.  

>scenario for prefix re-numbering ?

[Med] The CPE is not supposed to maintain the old IPv6 prefix. The text focuses on what happens if a new IPv6 prefix is assigned. 

>b) Step 4 - How different is this problem when compared with pure-IPv6 only

[Med] IPv6-only hosts can learn new IPv6 prefix from the new assigned prefix. In the DS-Lite context, hosts located behind the CPE may be IPv4-only and as such they have no means to be aware new IPv6 prefix is assigned to the CPE.  

>
>[5]
>
>Provide more details on why mappings cannot be re-used with the IPv6
>address change (but with no prefix change) and the need to clear mappings.
>[6] Step 6 in Section 4 - clarify what do mean by "clear all resources in
>use" ? (Are you referring to resetting the TCP connections ?)

[Med] clearing all NAT entries in the AFTR (including TCP sessions).

>
>[7] Include reference to security considerations given in
>http://tools.ietf.org/html/draft-ietf-pcp-dslite-00

[Med] i.e., active IPv4-in-IPv6 tunnel per subscriber.  

>    clarify what you mean by "stable prefix" ?

[Med] i.e., the same prefix is assigned to the CPE. In other words, avoid renumbering ;-)

>_______________________________________________
>pcp mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/pcp

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Mon, 12 Aug 2013 08:52:51 +0000

Hi Med,

Please see inline

> From: [email-masked] [mailto:[email-masked]]
> Sent: Monday, August 12, 2013 12:26 PM
> To: Tirumaleswar Reddy (tireddy); Suresh Kumar Vinapamula Venkata;
> [email-masked]
> Subject: RE: [pcp] New Version Notification for draft-vinapamula-softwire-
> [Med] The point of that step is to explicitly require policies to be enforced
> per subscriber and not per softwire. In order to avoid explicitly configuring
> IPv6 prefixes, the text suggest to configure the length of the prefix assigned
> to subscribers in that domain(e.g., 56 or 64). Doing so, would allow to
> include stale mappings in the quota in the event a new IPv6 address (from the
> same prefix) is assigned to the B4 element.

If policies are enforced per subscriber then I guess there is no need to clear the 
mapping (clear the NAT entries) even if IPv6 address changes (but prefix is not changed).

> [Med] This is a constraint on the B4 side. There some contexts which requires
> that address to change for some reasons (e.g., avoid receiving unsolicited
> traffic). The document explains how the service is not interrupted: migrate
> state to the new B4 IPv6 address.

If more details are provided in the draft on scenarios which mandate the address to change it will help.

> [Med] The CPE is not supposed to maintain the old IPv6 prefix. The text
> focuses on what happens if a new IPv6 prefix is assigned.

By "make before break" I was implying maintain both old and new IPv6 prefixes thus giving sometime for migration like being discussed in RFC 4191.

> [Med] IPv6-only hosts can learn new IPv6 prefix from the new assigned prefix.
> In the DS-Lite context, hosts located behind the CPE may be IPv4-only and as
> such they have no means to be aware new IPv6 prefix is assigned to the CPE.
> 
> >
> >[5]
> >

OK.

> [Med] i.e., active IPv4-in-IPv6 tunnel per subscriber.

Ok. 
Any specific reason why it could be more than 1 ?

> [Med] i.e., the same prefix is assigned to the CPE. In other words, avoid

Got it. Is it possible in future that for privacy reasons renumbering could happen more frequently ?

--Tiru.

---

From: <[email-masked]>
Date: Mon, 12 Aug 2013 11:12:26 +0200

Re-,

Please see inline.

Cheers,
Med

>De : Tirumaleswar Reddy (tireddy) [mailto:[email-masked]]
>Envoyé : lundi 12 août 2013 10:53
>À : BOUCADAIR Mohamed OLNC/OLN; Suresh Kumar Vinapamula Venkata;
>[email-masked]
>Objet : RE: [pcp] New Version Notification for draft-vinapamula-softwire-

[Med] Yes, entries are not cleared but are migrated to the new IPv6 address. This is indicated in Step 3:

   3.  In the event a new IPv6 address is assigned to B4, the AFTR
       SHOULD migrate existing state to be bound to the new B4's IP
       address.  This ensures the traffic destined to the previous IPv6
       address will redirected to the new IPv6 address.  The destination
       address for tunneling return traffic SHOULD be the last seen
       address from the CPE.  The source address of the tunnel would
       remain same as AFTR.

>address to change it will help.

[Med] Will consider updating this (old) text: 

   However, there can be change in B4 address for any reason, may be
   because of change in CPE device or may be because of security
   extensions enabled in generating the IPv6 address.

>By "make before break" I was implying maintain both old and new IPv6
>prefixes thus giving sometime for migration like being discussed in RFC
>4191.

[Med] This makes some assumptions on the way prefixes are assigned by the network and also the PCP client can uses the lifetime of assigned prefixes to clear mappings and install new ones. Retrieving the same external IP address and ports will depend on the hold-down timers configured on the AFTR side. Note, there is no way to indicate to the AFTR/PCP Server to migrate state from an old prefix to a new one.

>
>>
>> >b) Step 4 - How different is this problem when compared with pure-IPv6
>only
>> >devices ?
>>
>> >What is the problem in associating existing IPv4 mappings with a new
>IPv6
>> >address derived from the same prefix ?
>> >
>> >    clarify what you mean by "active softwires per subscriber" in step 1
>of
>> >section 4 and default value of 1 ?
>>

[Med] more than 1 may be configured for open wi-fi services for example: a tunnel for traffic belonging to the owner of the CPE and another tunnel for the traffic of visiting hosts. 

>Got it. Is it possible in future that for privacy reasons renumbering could

[Med] One typical use case I have in mind is to avoid SPIT if the same IPv6 address used by the B4 is also used by a SIP User agent co-located in the CPE. Generating random addresses can be an efficient way to reduce SPIT-like attacks.

>> >> >>Title:		 Recommendation for Prefix Binding in the Softwire
>DS-
>> >Lite
>> >> >>Context
>> >> >>http://www.ietf.org/internet-drafts/draft-vinapamula-softwire-
>dslite-
>> >pref
>> >> >>i
>> >> >>x-binding-00.txt
>> >> >>Status:

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Mon, 12 Aug 2013 10:10:46 +0000

Hi Med,

Please see inline 

> Sent: Monday, August 12, 2013 2:42 PM

That clarifies my doubt, Thanks.

Ok.

> [Med] This makes some assumptions on the way prefixes are assigned by the
> network and also the PCP client can uses the lifetime of assigned prefixes to
> clear mappings and install new ones. Retrieving the same external IP address
> and ports will depend on the hold-down timers configured on the AFTR side.
> Note, there is no way to indicate to the AFTR/PCP Server to migrate state from
> an old prefix to a new one.

Yes.

> [Med] more than 1 may be configured for open wi-fi services for example: a
> tunnel for traffic belonging to the owner of the CPE and another tunnel for
> the traffic of visiting hosts.
> 
> >
> >>
> [Med] One typical use case I have in mind is to avoid SPIT if the same IPv6
> address used by the B4 is also used by a SIP User agent co-located in the CPE.
> Generating random addresses can be an efficient way to reduce SPIT-like
> attacks.

--Tiru.