Subject: [pcp] Comments on draft-ietf-pcp-dhcp-03

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Fri, 3 Aug 2012 17:44:47 +0000

After reviewing draft-ietf-pcp-dhcp-03 I believe there are some things I
believe we need to tie up.

When a PCP Client contacts PCP Servers in parallel, say, IPx1, IPy1 and
IPz1 as mentioned in draft and all respond then:

1 - What happens to the state in y1 and z1 if PCP Client chooses x1 to
communicate? Probably let it age out or delete mappings.

2 - If there is a failure on x1 and PCP Client decides to communicate with
y1, there might be some 'leftover' mappings for internal IP:port (see 1).
PCP Client will need to delete or reuse existing state in y1. Important to
notice that there is no way to guarantee that PCP Server will allocate
same external IP:ports.

3 - I guess it is assumed that if PCP Server is co-located with NAT, if x1
fails, traffic (PCP and data) will be diverted to y1.

4 - Related (2). The draft says that when a PCP Server is unreachable
(say, y1) PCP Client will continue to try to communicate even though other
PCP Server are available.  The only way to 'communicate' is sending a
request, which might create state. So, when y1 is back up. y1 might
allocate a different external IP:port than other server.

Thanks,

Reinaldo

---

From: Dave Thaler <[email-masked]>
Date: Fri, 3 Aug 2012 17:53:11 +0000

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Reinaldo Penno (repenno)
> Sent: Friday, August 03, 2012 10:45 AM
> To: [email-masked]
> Subject: [pcp] Comments on draft-ietf-pcp-dhcp-03
> 

I agree.

> communicate? Probably let it age out or delete mappings.

What do you mean by "chooses x1"?   if we're talking about MAP (for a
listening application) do you mean when x, y, and y
are all NATs rather than FWs, and the client app can only deal with one
external IP address?

If they're firewalls (so the external IP address/port isn't different), or
if the client app can deal with multiple external IP/ports, then I don't think
it would choose one.
 
> 2 - If there is a failure on x1 and PCP Client decides to communicate with y1,
> there might be some 'leftover' mappings for internal IP:port (see 1).
> notice that there is no way to guarantee that PCP Server will allocate same
> external IP:ports.
> 
> 3 - I guess it is assumed that if PCP Server is co-located with NAT, if x1 fails,
> traffic (PCP and data) will be diverted to y1.

Unclear which model you're referring to (different external IP:port or
same external IP:port), can you clarify your question?
 
> 4 - Related (2). The draft says that when a PCP Server is unreachable (say, y1)
> PCP Client will continue to try to communicate even though other PCP Server
> are available.  The only way to 'communicate' is sending a request, which
> might create state. So, when y1 is back up. y1 might allocate a different
> external IP:port than other server.
> 
> Thanks,
> 
> Reinaldo
> 
> 
> 
> 
> _______________________________________________
> pcp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pcp

---

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Fri, 3 Aug 2012 18:18:23 +0000

On 8/3/12 10:53 AM, "Dave Thaler" <[email-masked]> wrote:

>What do you mean by "chooses x1"?

That's what we find in section 6.2

>if we're talking about MAP (for a

The draft says as soon as one PCP Server responds successfully it sticks
to it. So, I'm assuming other PCP Server are not contacted further and
mappings will time out or need to be deleted.

As a side effect why would an app get 3 external IP:ports for the same
purpose and consume three times the state. It seems to me a side effect of
the wording more than something the app really needs.

>if the client app can deal with multiple external IP/ports, then I don't

What's the use case for three? Anyway, this exchange is telling in light of

"Once the PCP Client has successfully
   received a response from a PCP Server on that interface, it sends
   subsequent PCP requests to that same server until that PCP Server
becomes non-responsive,"

>>same

The app needs one external IP:port to announce on the external world
through, say, DynDDNS client. Why it would need three _different_? If it
needs them, fine, not sure about use case. But if it gets 3 as a
collateral effect of the bootstrap procedure there is no way to guarantee
they will be the same.

>>(say, y1)

---

From: Dave Thaler <[email-masked]>
Date: Fri, 3 Aug 2012 20:29:41 +0000

Responding on list for benefit of others, although we already
talked in person...

> From: Reinaldo Penno (repenno) [mailto:[email-masked]]
> Sent: Friday, August 03, 2012 11:18 AM
> To: Dave Thaler; [email-masked]
> Subject: Re: Comments on draft-ietf-pcp-dhcp-03
> 
> >> After reviewing draft-ietf-pcp-dhcp-03 I believe there are some
> >> things I believe we need to tie up.
> >
> >I agree.
> >
> >> 1 - What happens to the state in y1 and z1 if PCP Client chooses x1
> >> to communicate? Probably let it age out or delete mappings.
> >

Yes but the text is lacking, as this exchange shows.

> >listening application) do you mean when x, y, and y are all NATs rather
> >than FWs, and the client app can only deal with one external IP
> >address?
> 
> The draft says as soon as one PCP Server responds successfully it sticks to it.
> So, I'm assuming other PCP Server are not contacted further and mappings
> will time out or need to be deleted.
> 

Two reasons (cases):
a) there's different networks it's providing the same service on, e.g.
    via the Internet and via some other network.
b) for failover purposes.   For example, if it uses SRV records, it'd have
   3 SRV records.   If one NAT goes down, the other end will automatically
   use a different IP:port pair (which might be via a different ISP).   Otherwise
   the failover time is capped at the TTL of the SRV record, and we know
   DNS TTLs below around 30 seconds aren't respected by many DNS servers.
   So having multiple records provides sub-30-second failover.

> >If they're firewalls (so the external IP address/port isn't different),
> >or if the client app can deal with multiple external IP/ports, then I
> >don't think it would choose one.
> 
> What's the use case for three? 

Answered above.   Note I'm not saying three is appropriate in all cases.
Only that there is a use case, and the choice is up to the client,
which is the only entity that knows the use case.

> Anyway, this exchange is telling in light of
> 
> >> 2 - If there is a failure on x1 and PCP Client decides to communicate
> >>with y1,  there might be some 'leftover' mappings for internal IP:port
> >>(see 1).
> >> PCP Client will need to delete or reuse existing state in y1.
> >>Important to  notice that there is no way to guarantee that PCP Server
> >>will allocate same  external IP:ports.
> >>
> >> 3 - I guess it is assumed that if PCP Server is co-located with NAT,
> >>if
> >>x1 fails,
> needs them, fine, not sure about use case. But if it gets 3 as a collateral effect
> of the bootstrap procedure there is no way to guarantee they will be the
> same.

Answered above.

-Dave
 
> >>(say, y1)  PCP Client will continue to try to communicate even though
> >>other PCP Server  are available.  The only way to 'communicate' is
> >>sending a request, which  might create state. So, when y1 is back up.
> >>y1 might allocate a different  external IP:port than other server.
> >>
> >> Thanks,
> >>
> >> Reinaldo

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Sun, 5 Aug 2012 21:45:46 +0000

Hi -

I think we need to clarify in the draft when multiple PCP server names/IP addresses will be returned by the DHCP server, for example like multi-homing case.

Considering various other cases other than multi-homing 

[1]In High Availability mode of NAT/Firewall devices (Active/Passive Mode), PCP client still gets just one IP address.

[2] For example in the draft http://tools.ietf.org/html/draft-rpcw-pcp-pmipv6-serv-discovery-00 where selected traffic is offload at the local access network. Mobile Node is provided only the PCP server address in the Local Access Network and MAG decides if the PCP request will be handled by Home network or Local Access Network.

[3] In Enterprise use case there could be two to three different possibilities

a)All the traffic from the branches tunneled back to the head office where there is a NAT/Firewall device.

b)Split Tunneling - In this case branch site itself would have NAT/Firewall to handle traffic to Internet. 
How will the DHCP server be populated with the right Firewall/NAT IP addresses in this case ?

[4]
Finally we will also need to solve the problem with just IPv6 (NPTv6, Firewall) where there is no DHCPv6 server.
>From RFC6106
"RA-based DNS configuration is a useful alternative in networks where an IPv6 host's address is auto-configured through IPv6 stateless
address auto-configuration and where there is either no DHCPv6 infrastructure at all or some hosts do not have a DHCPv6 client"

--Tiru.

> From: Dave Thaler [mailto:[email-masked]]
> Sent: Friday, August 03, 2012 2:30 PM
> To: Reinaldo Penno (repenno); [email-masked]
> Subject: Re: [pcp] Comments on draft-ietf-pcp-dhcp-03
> 
> > >> When a PCP Client contacts PCP Servers in parallel, say, IPx1,
> IPy1
> > >> and
> collateral effect

---

From: Dave Thaler <[email-masked]>
Date: Tue, 7 Aug 2012 01:34:38 +0000

> From: Tirumaleswar Reddy (tireddy) [mailto:[email-masked]]
> Sent: Sunday, August 5, 2012 2:46 PM
> To: Dave Thaler; Reinaldo Penno (repenno); [email-masked]
> Subject: RE: [pcp] Comments on draft-ietf-pcp-dhcp-03
> 
> Hi -
> 
> I think we need to clarify in the draft when multiple PCP server names/IP
> addresses will be returned by the DHCP server, for example like multi-homing
> case.

A small number of examples might be nice, but I don't think it can ever be complete,
and so we shouldn't try to enumerate all possible cases.

> [1]In High Availability mode of NAT/Firewall devices (Active/Passive Mode),
> PCP client still gets just one IP address.
> 
> [2] For example in the draft http://tools.ietf.org/html/draft-rpcw-pcp-pmipv6-
> serv-discovery-00 where selected traffic is offload at the local access network.
> Mobile Node is provided only the PCP server address in the Local Access
> Network and MAG decides if the PCP request will be handled by Home network
> or Local Access Network.
> 
> "RA-based DNS configuration is a useful alternative in networks where an IPv6
> host's address is auto-configured through IPv6 stateless address auto-
> configuration and where there is either no DHCPv6 infrastructure at all or
> some hosts do not have a DHCPv6 client"

I (with no hats) disagree that a no-DHCPv6 server case needs to be solved by this WG.

-Dave
 
> > Responding on list for benefit of others, although we already talked
> > in person...
> >
> > > >> From: [email-masked] [mailto:[email-masked]] On
> > > >> Behalf
> > Of
> > > >> Reinaldo Penno (repenno)
> > > through, say, DynDDNS client. Why it would need three _different_?
> > > If
> > it

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Tue, 7 Aug 2012 02:10:17 +0000

> and so we shouldn't try to enumerate all possible cases.

Yes, we need some examples.

--Tiru.

> Sent: Tuesday, August 07, 2012 7:05 AM
> To: Tirumaleswar Reddy (tireddy); Reinaldo Penno (repenno);
> [email-masked]
> > a)All the traffic from the branches tunneled back to the head office
> where
> > there is a NAT/Firewall device.
> >
> > b)Split Tunneling - In this case branch site itself would have
> NAT/Firewall to
> > handle traffic to Internet.
> > Finally we will also need to solve the problem with just IPv6 (NPTv6,
> Firewall)
> > where there is no DHCPv6 server.
> > From RFC6106
> talked
> > > > >> 1 - What happens to the state in y1 and z1 if PCP Client
> chooses
> > > x1
> > > b) for failover purposes.   For example, if it uses SRV records,
> it'd
> > > have
> > >    use a different IP:port pair (which might be via a different
> ISP).
> > > Otherwise
> > > > >or if the client app can deal with multiple external IP/ports,
> then
> > > I
> > > > >> 3 - I guess it is assumed that if PCP Server is co-located
> with
> > > NAT,
> > > > >>if
> > > > >>x1 fails,
> > > > >Unclear which model you're referring to (different external
> IP:port
> > > or
> > > > of the bootstrap procedure there is no way to guarantee they will
> be
> > > the
> > > > same.
> > >
> > > Answered above.
> > >
> > > -Dave
> > >
> > > > >>sending a request, which  might create state. So, when y1 is
> back
> > > up.

---

From: <[email-masked]>
Date: Tue, 7 Aug 2012 14:55:50 +0200

Dear Tiru,

I added this text to the draft to reflect your comment:

   Multiple Names may be configured to a PCP Client in some deployment
   contexts such as multi-homing.  It is out of scope of this document
   to enumerate all deployment scenarios which require multiple Names to
   be configured.

Cheers,
Med 

>-----Message d'origine-----
>De : [email-masked] [mailto:[email-masked]] De la 
>part de Tirumaleswar Reddy (tireddy)
>Envoyé : mardi 7 août 2012 04:10
>À : Dave Thaler; Reinaldo Penno (repenno); [email-masked]
>Objet : Re: [pcp] Comments on draft-ietf-pcp-dhcp-03
>
>> A small number of examples might be nice, but I don't think 
>it can ever
>> be complete,
>> A small number of examples might be nice, but I don't think 
>it can ever
>> be complete,
>> > [1]In High Availability mode of NAT/Firewall devices 
>(Active/Passive
>> Mode),
>> > How will the DHCP server be populated with the right 
>Firewall/NAT IP
>> > addresses in this case ?
>> >
>> > [4]
>> > "RA-based DNS configuration is a useful alternative in 
>networks where
>> an IPv6
>are all NATs
>> > > rather
>> > > > The draft says as soon as one PCP Server responds 
>successfully it
>> > > sticks to it.
>> > > > As a side effect why would an app get 3 external 
>IP:ports for the
>> > > same
>> > > > purpose and consume three times the state. It seems to 
>me a side
>> > > effect of
>> > >    the failover time is capped at the TTL of the SRV 
>record, and we
>> > > know
>> > > > >>with y1,  there might be some 'leftover' mappings 
>for internal
>> > > IP:port
>> > > > >>(see 1).
>> > > > >>Important to  notice that there is no way to 
>guarantee that PCP
>> > > Server
>> > > > >>(say, y1)  PCP Client will continue to try to 
>communicate even
>> > > though
>> > > > >>other PCP Server  are available.  The only way to 
>'communicate'
>> is

---

From: <[email-masked]>
Date: Tue, 7 Aug 2012 14:58:51 +0200

Dear all,

I added this text to the draft:

   The discovery procedure may result in a PCP Client instantiating
   multiple mappings maintained by distinct PCP Servers.  The decision to
   use all these mappings or delete some of them is deployment-specific.
   Only the client can decide whether all the mappings are needed or
   only a subset of them.

I don't think we can say more in this draft. This is really a deployment-specific issue. 

Cheers,
Med 

>part de Dave Thaler
>Envoyé : vendredi 3 août 2012 22:30
>À : Reinaldo Penno (repenno); [email-masked]
>> >> When a PCP Client contacts PCP Servers in parallel, say, 
>IPx1, IPy1
>> >> and
>chooses x1
>successfully it sticks to it.
>IP:port or

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Wed, 8 Aug 2012 06:03:18 +0000

> From: [email-masked]
> [mailto:[email-masked]]
> Sent: Tuesday, August 07, 2012 6:26 PM
> To: Tirumaleswar Reddy (tireddy); [email-masked]
>    to enumerate all deployment scenarios which require multiple Names
>    to be configured.

Hi Med -

The text looks good. If you can highlight at least one use case of multi-homing you have in mind that would be great (An example in the Appendix would also work)

--Tiru.

> >> > [2] For example in the draft http://tools.ietf.org/html/draft-
> rpcw-
> >> pcp-pmipv6-
> >> > configuration and where there is either no DHCPv6 infrastructure
> at
> >> all or
> >> > > > So, I'm assuming other PCP Server are not contacted further
> and
> >> > > mappings
> >> > > a) there's different networks it's providing the same service
> on,
> >> e.g.
> >> > > Answered above.   Note I'm not saying three is appropriate in
> all
> >> > > cases.