Subject: [pcp] Comments on draft-ietf-pcp-dslite-00. (PCP DS-Lite Handling)

From: Suresh Kumar Vinapamula Venkata <[email-masked]>
Date: Wed, 19 Jun 2013 23:59:30 +0000

Hi,

An external IP address of the CPE device may change as and when DHCP lease expires or when there is a reboot of CPE for any reason.
Traffic destined from external world, to these mappings, may not reach intended CPE, as there is change in external address.
RFC 6887 recommends no host renumbering to handle it.

However this is not sufficient in v6 environment especially with DS-Lite, where a CPE is assigned a v6prefix and is free to use any address with in the prefix. Though DHPCv6 may assign same prefix to a CPE, the host portion is typically filled by CPE and typically with mac address, which changes when there is a change in CPE device or for some reason.

Since the end systems (Hosts behind CPE/B4, and the CGN box) has not rebooted, the mappings that were created before and the traffic destined to those mappings if tunneled over to old B4 address would be dropped by the CPE device.

This also causes other inconvenience as these mappings hangs around till they timeout(scaling impact and non usage of ports and memory) or, unless, a packet faked with the old B4 address as source and a delete request is issued. Even if those mappings are deleted  in someway, a new set of mappings have to be created and published for external world to connect, every time, when such an event happens.

This is a scenario, where end systems(hosts behind B4 and CGNAT device) are not rebooted, but intermediate CPE device is rebooted.

Since the end systems are not rebooted, can those mappings be migrated over DS-Lite tunnels?

There are two options here, to reuse these mappings.

  1.  The option is, create mappings and flows on per prefix. This way mappings and flows are migrated to any address in the same prefix when ever there is change in address. The destination address to be used by the CGNAT box, to tunnel packets over those mappings to the CPE should be the address last seen by the CGNAT from the CPE of the prefix. This way, traffic over mappings and flows created over old B4 address, can continue to reach intended host over the new DS-Lite tunnel.
  2.  CPE to accept packets destined to any address in that prefix. This may be a generic stack change and may not be desirable.

This is not covered in http://trac.tools.ietf.org/html/draft-ietf-pcp-dslite-00. Can this be included for the discussion?

Please comment.

-Suresh

---

From: <[email-masked]>
Date: Thu, 20 Jun 2013 15:24:38 +0200

Dear Suresh,

FWIW, you may find some text describing this failure case at: http://tools.ietf.org/html/draft-boucadair-pcp-failure-06#section-2.5.

Cheers,
Med

De : [email-masked] [mailto:[email-masked]] De la part de Suresh Kumar Vinapamula Venkata
Envoyé : jeudi 20 juin 2013 02:00
À : [email-masked]
Cc : [email-masked]; [email-masked]
Objet : [pcp] Comments on draft-ietf-pcp-dslite-00. (PCP DS-Lite Handling)

Hi,

Please comment.

-Suresh

---

From: Suresh Kumar Vinapamula Venkata <[email-masked]>
Date: Thu, 20 Jun 2013 15:05:37 +0000

Hi Mohammed

Please correct me if I am missing some thing. How can CGNAT know, whether the request is to refresh existing mappings or for new mappings when the CPE address changed?
Addresses behind B4 can overlap right? They have to rely on B4 address right?

Suresh

On Jun 20, 2013, at 6:25 AM, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>> wrote:

Dear Suresh,

Cheers,
Med

De : [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] De la part de Suresh Kumar Vinapamula Venkata
Envoyé : jeudi 20 juin 2013 02:00
À : [email-masked]<mailto:[email-masked]>
Cc : [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Objet : [pcp] Comments on draft-ietf-pcp-dslite-00. (PCP DS-Lite Handling)

Hi,

Please comment.

-Suresh

---

From: <[email-masked]>
Date: Fri, 21 Jun 2013 11:02:45 +0200

Hi Suresh,

If a new address is assigned to the B4, the co-located PCP client will need to re-install the mappings it manages. This will be seen by the PCP server as new requests if the PCP Client IP Address is not already in use in table or refresh mappings otherwise. In both cases, there is a failure risk due to the presence of stale mappings. You can check: http://tools.ietf.org/html/draft-boucadair-pcp-failure-06#section-2.4

Cheers,
Med

De : Suresh Kumar Vinapamula Venkata [mailto:[email-masked]]
Envoyé : jeudi 20 juin 2013 17:06
À : BOUCADAIR Mohamed OLNC/OLN
Cc : [email-masked]; [email-masked]; [email-masked]
Objet : Re: Comments on draft-ietf-pcp-dslite-00. (PCP DS-Lite Handling)

Hi Mohammed

Suresh

Cheers,
Med

Hi,

Please comment.

-Suresh

---

From: Dan Wing <[email-masked]>
Date: Fri, 21 Jun 2013 15:55:02 -0700

On Jun 21, 2013, at 2:02 AM, [email-masked] wrote:

> Hi Suresh,
>  
> If a new address is assigned to the B4, the co-located PCP client will need to re-install the mappings it manages.

When a new address is assigned to the B4, the B4's PCP server should follow the procedures in "Address Change Events", http://tools.ietf.org/html/rfc6887#section-11.5.  The host which created the mappings (the PCP client) needs to be aware of the address change to update the information in the rendezvous server (DNS, SIP, XMPP, whatever), which means the B4's PCP server isn't helping things by updating mappings on the CGN by itself.

-d

> This will be seen by the PCP server as new requests if the PCP Client IP Address is not already in use in table or refresh mappings otherwise. In both cases, there is a failure risk due to the presence of stale mappings. You can check: http://tools.ietf.org/html/draft-boucadair-pcp-failure-06#section-2.4
>  
> Cheers,
> Med
>  
> On Jun 20, 2013, at 6:25 AM, "[email-masked]" <[email-masked]> wrote:
> 
> Dear Suresh,
>  
> FWIW, you may find some text describing this failure case at:http://tools.ietf.org/html/draft-boucadair-pcp-failure-06#section-2.5.
>  
> Cheers,
> Med
>  
> 	• The option is, create mappings and flows on per prefix. This way mappings and flows are migrated to any address in the same prefix when ever there is change in address. The destination address to be used by the CGNAT box, to tunnel packets over those mappings to the CPE should be the address last seen by the CGNAT from the CPE of the prefix. This way, traffic over mappings and flows created over old B4 address, can continue to reach intended host over the new DS-Lite tunnel. 
> 	• CPE to accept packets destined to any address in that prefix. This may be a generic stack change and may not be desirable.
> _______________________________________________
> pcp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pcp

---

From: Suresh Kumar Vinapamula Venkata <[email-masked]>
Date: Sat, 22 Jun 2013 00:37:15 +0000

Hi Mohamed/Dan, 

Thanks for pointing to the drafts.
I understand from the drafts that if a CPE is assigned a same IP address
after reboot, in case of DS-Lite, PCP proxy should send ANNOUNCE request
to the PCP clients.
This way, PCP clients would refresh their mappings.

Suppose prefix say 3001::/56 is assigned to CPE after reboot and is same
as before reboot.
Suppose IPv6 address before reboot is 3001::a and created some mappings.

However, after a reboot, a new IPv6 address may be taken as B4 say
3001::b. 
As per the current drafts, clients will try to refresh mappings with the
newly assigned IPv6 address as the B4 address.
Since the requests are from the different IPv6 address, CGNAT will try to
create new mappings and the old mappings have to age out.
Now hosts using these mappings have to publish these mappings, for
external hosts to connect right? This is an overhead.

My point is, this over head can be eliminated when there is a change in
address in the prefix, why do we need to force creation of new mappings
and timeout of old mappings?
Instead, can the mappings and the corresponding traffic be migrated to
newer B4? 
If the same address is acquired by the B4 after reboot, CGNAT box doesn't
differentiate right? I am suggesting can this be extended to prefix, such
that any mappings created over one B4 address of the prefix be migrated to
another B4 address within the same prefix?

If there is a change in prefix, there is no option to migrate as
mentioned, new mappings have to be created and old mappings have to
expire. 
Address change with in a prefix can be handled more gracefully right? Am I
missing something?

-Suresh

On 6/21/13 3:55 PM, "Dan Wing" <[email-masked]> wrote:

>> If a new address is assigned to the B4, the co-located PCP client will
>>need to re-install the mappings it manages.
>
>When a new address is assigned to the B4, the B4's PCP server should
>follow the procedures in "Address Change Events",
>http://tools.ietf.org/html/rfc6887#section-11.5.  The host which created
>the mappings (the PCP client) needs to be aware of the address change to
>update the information in the rendezvous server (DNS, SIP, XMPP,
>whatever), which means the B4's PCP server isn't helping things by
>updating mappings on the CGN by itself.
>
>-d
>
>
>> This will be seen by the PCP server as new requests if the PCP Client
>>IP Address is not already in use in table or refresh mappings otherwise.
>>In both cases, there is a failure risk due to the presence of stale
>>mappings. You can check:
>>http://tools.ietf.org/html/draft-boucadair-pcp-failure-06#section-2.4
>>  
>> Cheers,
>> Med
>>  
>> Please correct me if I am missing some thing. How can CGNAT know,
>>whether the request is to refresh existing mappings or for new mappings
>>when the CPE address changed?
>> FWIW, you may find some text describing this failure case
>>at:http://tools.ietf.org/html/draft-boucadair-pcp-failure-06#section-2.5.
>>  
>> Cheers,
>> Med
>>  
>> An external IP address of the CPE device may change as and when DHCP
>>lease expires or when there is a reboot of CPE for any reason.
>> Traffic destined from external world, to these mappings, may not reach
>>intended CPE, as there is change in external address.
>> However this is not sufficient in v6 environment especially with
>>DS-Lite, where a CPE is assigned a v6prefix and is free to use any
>>address with in the prefix. Though DHPCv6 may assign same prefix to a
>>CPE, the host portion is typically filled by CPE and typically with mac
>>address, which changes when there is a change in CPE device or for some
>>reason. 
>>  
>> Since the end systems (Hosts behind CPE/B4, and the CGN box) has not
>>rebooted, the mappings that were created before and the traffic destined
>>to those mappings if tunneled over to old B4 address would be dropped by
>>the CPE device. 
>>  
>> This also causes other inconvenience as these mappings hangs around
>>till they timeout(scaling impact and non usage of ports and memory) or,
>>unless, a packet faked with the old B4 address as source and a delete
>>request is issued. Even if those mappings are deleted  in someway, a new
>>set of mappings have to be created and published for external world to
>>connect, every time, when such an event happens.
>>  
>> This is a scenario, where end systems(hosts behind B4 and CGNAT device)
>>are not rebooted, but intermediate CPE device is rebooted.
>>  
>> 	€ The option is, create mappings and flows on per prefix. This way
>>mappings and flows are migrated to any address in the same prefix when
>>ever there is change in address. The destination address to be used by
>>the CGNAT box, to tunnel packets over those mappings to the CPE should
>>be the address last seen by the CGNAT from the CPE of the prefix. This
>>way, traffic over mappings and flows created over old B4 address, can
>>continue to reach intended host over the new DS-Lite tunnel.
>> 	€ CPE to accept packets destined to any address in that prefix. This
>>may be a generic stack change and may not be desirable.
>> This is not covered in
>>http://trac.tools.ietf.org/html/draft-ietf-pcp-dslite-00. Can this be
>>included for the discussion?
>>  
>> Please comment.
>>  
>> -Suresh

---

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Sat, 22 Jun 2013 01:16:42 +0000

It seems you are suggesting a per prefix binding. So, in your example if
internal host 10.0.0.2 sends a new MAP request that uses 3001:b as source
address, the AFTR should update any existing mappings to use this new
source IPv6 to reach the B4 while external public IP:port would be the
same. Therefore no need to update dynDNS or other stuff.

If my understanding is correct this is interesting.

---

From: Dan Wing <[email-masked]>
Date: Fri, 21 Jun 2013 19:08:41 -0700

> If my understanding is correct this is interesting.

Thanks for summarizing - I understand the proposal now.  It seems to require the B4 and the AFTR know that the same IPv4 mapping is available after IPv6 renumbering -- specifically that the same AFTR is being used and it will assign the same IPv4 address to the B4.  Seems a lot of coordination between the B4 and AFTR to avoid updating a rendezvous server.  However, the host (and the B4) will always need to be able to handle network renumbering where the same IPv4 mapping is not available, so this increases implementation and testing effort.  The gain, in my mind, is pretty small especially considering the IP renumbering has to be infrequent (or else TCP sessions are disrupted, nobody much appreciates that).

-d

---

From: Suresh Kumar Vinapamula Venkata <[email-masked]>
Date: Sat, 22 Jun 2013 04:32:19 +0000

Yes Reinaldo, that is correct.

Dan, 

Note, it is the CPE that rebooted or went bad and so changed.
End systems are not rebooted.

With no renumbering CPE is assigned same v6 prefix 3001::.
Depending on the algorithm to fill in the host portion forming a B4
prefix, a new B4 address 3001::b can be picked which is different from old
B4 address 3001::a.

Since the end systems 10.0.0.2 haven't rebooted, they should be able to
continue using those mappings. When hosts behind B4 sees ANNOUNCE, and
sends refresh requests, it would not result in creating a new mapping but
use existing mapping. The benefit, hosts behind B4 don't need to publish
to external world about the change, to receive traffic from external world.

Consider a case where an IPv6 address is assigned and not prefix to the
CPE.
If the same IPv6 address assigned after reboot or change of CPE, hosts on
seeing PCP ANNOUNCE, when refreshes their mappings, PCP server responses
back with the existing mapping, it is not going to create new set of
mappings and age out existing mappings right?

I am extending the same argument to prefixes, where CPEs are assigned with
prefixes and are free to use any v6 address in the prefix as B4 address.
So, change in that address should not result in creating new mappings and
age out old mappings.

Suppose if we go with the approach defined in the drafts where new
mappings have to be created when there is change in address, as an
attacker, I can exhaust CGNAT/PCP server resources, by picking multiple
IPv6 addresses with in the assigned prefix as B4 and faking PCP requests.

If we limit the resources on per prefix bases on CGNAT/PCP, then as a
genuine user when there is a change in B4 address, I will not be able to
create and use all my quota of mappings, as there would be some stale
mappings created before my B4 change eating my quota. And the traffic
destined to those mappings from internet would be processed by CGNAT box
only to be dropped at CPE!

Please comment.

Suresh

On 6/21/13 7:08 PM, "Dan Wing" <[email-masked]> wrote:

>Thanks for summarizing - I understand the proposal now.  It seems to
>require the B4 and the AFTR know that the same IPv4 mapping is available
>after IPv6 renumbering -- specifically that the same AFTR is being used
>and it will assign the same IPv4 address to the B4.  Seems a lot of
>coordination between the B4 and AFTR to avoid updating a rendezvous
>server.  However, the host (and the B4) will always need to be able to
>handle network renumbering where the same IPv4 mapping is not available,
>so this increases implementation and testing effort.  The gain, in my
>mind, is pretty small especially considering the IP renumbering has to be
>infrequent (or else TCP sessions are disrupted, nobody much appreciates
>that).
>
>-d
>
>
>> 
>>>>> Addresses behind B4 can overlap right? They have to rely on B4
>>>>>address
>>>>> right?
>>>>> 
>>>>> Suresh
>>>>> 
>>>>>at:http://tools.ietf.org/html/draft-boucadair-pcp-failure-06#section-2
>>>>>.5
>>>>> .
>>>>> 
>>>>> Cheers,
>>>>> Med
>>>>> 
>>>>> Since the end systems are not rebooted, can those mappings be
>>>>>migrated
>>>>> over DS-Lite tunnels?
>>>>>

---

From: Dan Wing <[email-masked]>
Date: Fri, 21 Jun 2013 22:06:31 -0700

> to external world about the change, to receive traffic from external world.

What are the security implications of 3001::b taking over 3001::a's mappings?  Is there a way to ensure that doesn't happen maliciously?

> IPv6 addresses with in the assigned prefix as B4 and faking PCP requests.

That attack is still possible with your idea.  The mitigation, with or without your idea, is that the AFTR has to apply its port quota to the entirety of the IPv6 prefix assigned to a B4 -- the entire "subscriber", if you will -- typically the entire /64.  That seems an important point to include in draft-ietf-pcp-dslite.

> mappings created before my B4 change eating my quota.

Ignoring PCP for a moment, that problem exists with implicit mappings if the ISP renumbers hosts behind the CGN.  I admit that PCP's long lifetimes can make that problem worse.  One easy solution is to reduce the maximum assigned PCP lifetime on the CGN prior to an address change event -- much like we do with lowering DNS TTL prior to changing DNS records.  But perhaps it is operationally difficult to know when an address change is going to occur.  A slightly more difficult solution, which works even if address changes aren't planned, is to send a PCP THIRD_PARTY delete message from the ISP's management system when an address change occurs.

> And the traffic

But the CPE dropping those packets is not a new or significant problem when the ISP renumbered the subscriber.  Such dropping of packets would happen on today's IPv4 Internet if the ISP renumbered two subscribers to suddenly have each other's IP addresses -- packets would be routed to the wrong home and get dropped by NATs or host-based firewalls, or (if they aren't dropped) the packets would be processed by the host to confuse TCP stacks or applications.

-d

---

From: Suresh Kumar Vinapamula Venkata <[email-masked]>
Date: Sat, 22 Jun 2013 08:02:04 +0000

On 6/21/13 10:06 PM, "Dan Wing" <[email-masked]> wrote:

>What are the security implications of 3001::b taking over 3001::a's
>mappings?  Is there a way to ensure that doesn't happen maliciously?

Since Since they are from the same prefix, and the prefix len
configuration is under admin control, I am not thinking of any _new_
malicious attacks.
If you think of any such scenarios, can you please point them?

>That attack is still possible with your idea.  The mitigation, with or
>without your idea, is that the AFTR has to apply its port quota to the
>entirety of the IPv6 prefix assigned to a B4 -- the entire "subscriber",
>if you will -- typically the entire /64.  That seems an important point
>to include in draft-ietf-pcp-dslite.
Yes, resources have to be configured on per prefix basis. In addition to
that, if we are not migrating mappings, you would be eating up the quota
because of the stale mappings that I mentioned below right?
>Ignoring PCP for a moment, that problem exists with implicit mappings if
>the ISP renumbers hosts behind the CGN.  I admit that PCP's long
>lifetimes can make that problem worse.  One easy solution is to reduce
>the maximum assigned PCP lifetime on the CGN prior to an address change
>event -- much like we do with lowering DNS TTL prior to changing DNS
>records.  But perhaps it is operationally difficult to know when an
>address change is going to occur.  A slightly more difficult solution,
>which works even if address changes aren't planned, is to send a PCP
>THIRD_PARTY delete message from the ISP's management system when an
>address change occurs.
Yes, with renumbering this issue arises. That is why we recommend no
renumbering right? In this scenario, prefix renumbering has not occurred,
and it is the IPv6 address that changed with in the prefix. Yes, shorter
life time works, but I feel that adds syslog(capturing mappings tuples)
over head.
When address/prefix renumbering happens, I agree a third party delete msgs
or a clear command, may be issued by admin.
I feel it is an over kill to use this when an address with in the prefix
changes and no subscriber renumbering of prefix happened.
This is because when mappings are deleted, their associate state like
flows have to be deleted.
This can cause lot of churn when deletion happens at the same time for
multiple addresses.

>But the CPE dropping those packets is not a new or significant problem
>when the ISP renumbered the subscriber.  Such dropping of packets would
>happen on today's IPv4 Internet if the ISP renumbered two subscribers to
>suddenly have each other's IP addresses -- packets would be routed to the
>wrong home and get dropped by NATs or host-based firewalls, or (if they
>aren't dropped) the packets would be processed by the host to confuse TCP
>stacks or applications.
Note, ISP has not renumbered the subscriber while assigning prefix. It is
the IPv6 address derived out of the prefix that changed causing this. All
I am suggesting is, just like when address is assigned, without
renumbering subscriber, you carry over mappings across reboot. Similarly
when prefix is assigned without renumbering subscriber, even if addresses
within the prefix change I feel mappings can be carried across addresses
within the prefix, and in addition we have to have per prefix limits, as
"subscriber" is represented by prefix and not IPv6 address.

I feel when there is no renumbering of subscriber while assigning prefix,
it should be treated the same as when there is as address assignment
without renumbering of subscriber. The value I see here is, hosts behind
B4, can directly use the mappings, and republishing of those mappings to
external world can be avoided, effective utilization of port limit quota
and other CGNAT resources. Yes, we have to debate if it introduces any
issues.
>>>>> Since the requests are from the different IPv6 address, CGNAT will
>>>>>try
>>>>> to
>>>>>> the mappings (the PCP client) needs to be aware of the address
>>>>>>change
>>>>>> to
>>>>>>> De : [email-masked] [mailto:[email-masked]] De la part
>>>>>>>de
>>>>>>> Suresh Kumar Vinapamula Venkata
>>>>>>> request is issued. Even if those mappings are deleted  in someway,
>>>>>>>a
>>>>>>> new

---

From: <[email-masked]>
Date: Mon, 24 Jun 2013 08:54:23 +0200

Hi Suresh, 

Please see inline.
Cheers,
Med

>-----Message d'origine-----
>Envoyé : samedi 22 juin 2013 02:37
>À : Dan Wing; BOUCADAIR Mohamed OLNC/OLN
>Cc : [email-masked]; [email-masked]; [email-masked]
>Objet : Re: [pcp] Comments on draft-ietf-pcp-dslite-00. (PCP DS-Lite Handling)
>
>Hi Mohamed/Dan,
>

[Med] This proposal is not pcp-specific. It can be applied for all the traffic in case only one B4 is assumed to be mounted in the customer side + a new address that belongs to the same prefix is assigned to B4. 

>mentioned, new mappings have to be created and old mappings have to
[Med] Yes.

---

From: Suresh Kumar Vinapamula Venkata <[email-masked]>
Date: Mon, 24 Jun 2013 16:01:29 +0000

Hi Mohamed 

Yes it can be extended to other traffic. 

When it comes to flows, typically they are short lived and so they may expire even before they are migrated. 

Pcp creates mappings that can be long lived, and there is an effort involved in publishing those mappings for connectivity from external world. Also there is a conservation of NAT resources, and so the discussion.

Just curious, is there a reason why there would be more than one B4 on customer end? 

Suresh

---

From: Dan Wing <[email-masked]>
Date: Mon, 24 Jun 2013 09:25:50 -0700

> configuration is under admin control, I am not thinking of any _new_

Nothing comes immediately to mind.  When the details are written down it will bear careful consideration.

Separate from security implications, I remain skeptical of how often a B4 element would forget its previous IPv6 address or the network would refuse to give its old address back, yet the B4 is still able to remember mappings (to re-validate the mappings with the AFTR).

-d

---

From: Suresh Kumar Vinapamula Venkata <[email-masked]>
Date: Mon, 24 Jun 2013 17:57:42 +0000

>will bear careful consideration.
I agree. I thought about it and could not come up with any _new_ malicious
attacks, I think more.
>
>
>Separate from security implications, I remain skeptical of how often a B4
>element would forget its previous IPv6 address or the network would
>refuse to give its old address back, yet the B4 is still able to remember
>mappings (to re-validate the mappings with the AFTR).
It is not for B4, these mappings are created. It is for the hosts behind
B4 that these mappings are created. Does B4 need to be stateful for these
mappings?

When ever proxy/B4 reboots or changed, it is supposed to broadcast an
ANNOUNCE in its network, for the hosts behind it to refresh their
mappings. This is suggested in multiple drafts.
All I am trying suggest is to extend this to prefix level, where a prefix
is assigned to CPE. Hosts behind B4 on seeing ANNOUNCE, initiate mapping
refresh requests, CGNAT when tracked mappings at prefix level, would be
able to migrate these mappings even to newer B4. This will conserve
resources and, avoid overhead which we know when there is subscriber
renumbering.
 
If this is not done, even if admin ensures no subscriber renumbering of
prefix, it doesn't guaranty that hosts can continue using mappings they
previously created as B4 address may change.

>>>>>> It seems you are suggesting a per prefix binding. So, in your
>>>>>>example
>>>>>> if
>>>>> mind, is pretty small especially considering the IP renumbering has
>>>>>to
>>>>> be
>>>>>>> As per the current drafts, clients will try to refresh mappings
>>>>>>>with
>>>>>>> the
>>>>>>> My point is, this over head can be eliminated when there is a
>>>>>>>change
>>>>>>> in
>>>>>>> differentiate right? I am suggesting can this be extended to
>>>>>>>prefix,
>>>>>>> such
>>>>>>> Address change with in a prefix can be handled more gracefully
>>>>>>>right?
>>>>>>> Am I
>>>>>>> missing something?
>>>>>>> 
>>>>>>> -Suresh
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>>>>http://tools.ietf.org/html/draft-boucadair-pcp-failure-06#section-
>>>>>>>>>2.
>>>>>>>>> 4
>>>>>>>>> 
>>>>>>>>> Cheers,
>>>>>>>>> Med
>>>>>>>>> 
>>>>>>>>>at:http://tools.ietf.org/html/draft-boucadair-pcp-failure-06#secti
>>>>>>>>>on
>>>>>>>>> -2
>>>>>>>>> .5
>>>>>>>>> .
>>>>>>>>> 
>>>>>>>>> Cheers,
>>>>>>>>> Med
>>>>>>>>> 
>>>>>>>>> CPE, the host portion is typically filled by CPE and typically
>>>>>>>>>with
>>>>>>>>> mac
>>>>>>>>> address, which changes when there is a change in CPE device or
>>>>>>>>>for
>>>>>>>>> some
>>>>>>>>> reason. 
>>>>>>>>> 
>>>>>>>>> till they timeout(scaling impact and non usage of ports and
>>>>>>>>>memory)
>>>>>>>>> or,
>>>>>>>>> set of mappings have to be created and published for external
>>>>>>>>>world
>>>>>>>>> to
>>>>>>>>> ever there is change in address. The destination address to be
>>>>>>>>>used
>>>>>>>>> by
>>>>>>>>> http://trac.tools.ietf.org/html/draft-ietf-pcp-dslite-00. Can
>>>>>>>>>this
>>>>>>>>> be

---

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Mon, 24 Jun 2013 18:37:03 +0000

On 6/24/13 2:57 PM, "Suresh Kumar Vinapamula Venkata"
<[email-masked]> wrote:

>>>>> prefix, a new B4 address 3001::b can be picked which is different
>>>>>from
>>>>> old
>>>>> B4 address 3001::a.
>>>>> 

I was assuming PCP Proxy does not need to keep any state around. That's
why (apart from Dan's concerns) the scenario was very crisp in my mind.

>>>>> If the same IPv6 address assigned after reboot or change of CPE,
>>>>>hosts
>>>>> on
>>>>>>>> Suppose prefix say 3001::/56 is assigned to CPE after reboot and
>>>>>>>>is
>>>>>>>> same
>>>>>>>> as before reboot.
>>>>>>>> Instead, can the mappings and the corresponding traffic be
>>>>>>>>migrated
>>>>>>>> to
>>>>>>>> newer B4? 
>>>>>>>>>> If a new address is assigned to the B4, the co-located PCP
>>>>>>>>>>client
>>>>>>>>>> will
>>>>>>>>>> mappings and flows are migrated to any address in the same
>>>>>>>>>>prefix
>>>>>>>>>> when
>>>>>>>>>> be the address last seen by the CGNAT from the CPE of the
>>>>>>>>>>prefix.
>>>>>>>>>> This
>>>>>>>>>> way, traffic over mappings and flows created over old B4
>>>>>>>>>>address,
>>>>>>>>>> can

---

From: <[email-masked]>
Date: Tue, 25 Jun 2013 08:05:04 +0200

Hi Suresh,

Please see inline.
Cheers,
Med

>Envoyé : lundi 24 juin 2013 18:01
>Cc : Dan Wing; [email-masked]; [email-masked]; [email-masked]
>Pcp creates mappings that can be long lived, and there is an effort
>involved in publishing those mappings for connectivity from external world.
[Med] FWIW, you can check http://tools.ietf.org/html/draft-deng-pcp-ddns-02 

>Also there is a conservation of NAT resources, and so the discussion.
[Med] I do understand this and I'm supportive to work on those issues. 

>Just curious, is there a reason why there would be more than one B4 on
[Med] We have requested this feature mainly for dimensioning considerations on the AFTR side. For port quota checks (and other controls), we rely on the prefix mask to enforce policies.

>> [Med] This proposal is not pcp-specific. It can be applied for all the
>traffic in case only one B4 is assumed to be mounted in the customer side +
>a new address that belongs to the same prefix is assigned to B4.
>>
>>>

---

From: Suresh Kumar Vinapamula Venkata <[email-masked]>
Date: Tue, 25 Jun 2013 07:47:11 +0000

Sent from my iPhone

> [Med] FWIW, you can check http://tools.ietf.org/html/draft-deng-pcp-ddns-02 

This draft makes sense when there is a change in mapping. But the question is do we need to force change of mapping for the scenario that I described? 
> [Med] I do understand this and I'm supportive to work on those issues. 

With the approach that I extended, dont we conserve resources?
> [Med] We have requested this feature mainly for dimensioning considerations on the AFTR side. For port quota checks (and other controls), we rely on the prefix mask to enforce policies.

That is not sufficient right, as full quota may not be available when there is a change in B4, even if you ensured no subscriber renumbering while assigning prefix?

---

From: <[email-masked]>
Date: Tue, 25 Jun 2013 10:05:39 +0200

Re-,

Please see inline.
Cheers,
Med

>Envoyé : mardi 25 juin 2013 09:47
>This draft makes sense when there is a change in mapping. But the question
>is do we need to force change of mapping for the scenario that I described?
[Med] The change you proposed make sense to me if the same prefix is assigned to the CPE. If a new prefix is assigned, because of stale mappings, new external IP address and/or external ports will be assigned by the server. 

>With the approach that I extended, dont we conserve resources?
[Med] It does. This is why I suggested to extend your proposal to not be restricted to PCP-created mappings but be a generic behavior of the AFTR when it detects a new IP address from the same prefix is in use. External IP address and ports are not impacted in such case. 

>> [Med] We have requested this feature mainly for dimensioning
>considerations on the AFTR side. For port quota checks (and other
>controls), we rely on the prefix mask to enforce policies.
>
>That is not sufficient right, as full quota may not be available when there
>is a change in B4, even if you ensured no subscriber renumbering while
>assigning prefix?
[Med] If the same prefix is assigned to a CPE after reboot, and assuming mapping migration procedure you suggested, port quota is not impacted by any stale mapping. Complications arise when a new prefix is assigned and mappings found to an address from that prefix are already in use in the server.

---

From: Suresh Kumar Vinapamula Venkata <[email-masked]>
Date: Tue, 25 Jun 2013 19:03:37 +0000

Thanks for the clarification on your stand.

As mentioned in my previous mail, yes this can be extended. And the list I could think of as 

EIM,
EIF,
Mapped IP in case of APP, 
Flows, 
PCP, PCP being special case of (EIM/EIF/Flows)
NAT POOL limits.
Flow limits.

Let us add more to the list. 

Suresh> In that case I would say, server is not supposed to assign a prefix until all the mappings or references to that prefix are cleared.

________________________________________
From: [email-masked] [[email-masked]]
Sent: Tuesday, June 25, 2013 1:05 AM
To: Suresh Kumar Vinapamula Venkata
Cc: Dan Wing; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [pcp] Comments on draft-ietf-pcp-dslite-00. (PCP DS-Lite Handling)

Re-,

Please see inline.
Cheers,
Med