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

["Tirumaleswar Reddy (tireddy)" <[e-mail]>]

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.

> -----Original Message-----
> From: Dave Thaler [mailto:[e-mail]]
> Sent: Friday, August 03, 2012 2:30 PM
> To: Reinaldo Penno (repenno); [e-mail]
> Subject: Re: [pcp] Comments on draft-ietf-pcp-dhcp-03
> 
> Responding on list for benefit of others, although we already
> talked in person...
> 
> > -----Original Message-----
> > From: Reinaldo Penno (repenno) [mailto:[e-mail]]
> > Sent: Friday, August 03, 2012 11:18 AM
> > To: Dave Thaler; [e-mail]
> > Subject: Re: Comments on draft-ietf-pcp-dhcp-03
> >
> > On 8/3/12 10:53 AM, "Dave Thaler" <[e-mail]> wrote:
> >
> > >> -----Original Message-----
> > >> From: [e-mail] [mailto:[e-mail]] On Behalf
> Of
> > >> Reinaldo Penno (repenno)
> > >> Sent: Friday, August 03, 2012 10:45 AM
> > >> To: [e-mail]
> > >> Subject: [pcp] 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.
> > >
> > >> 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.
> > >
> > >What do you mean by "chooses x1"?
> >
> > That's what we find in section 6.2
> 
> Yes but the text is lacking, as this exchange shows.
> 
> > >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?
> >
> > 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.
> 
> 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
> >
> > "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,"
> >
> > >
> > >> 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.
> > >
> > >Unclear which model you're referring to (different external IP:port
> or
> > >same external IP:port), can you clarify your question?
> >
> > 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.
> 
> Answered above.
> 
> -Dave
> 
> > >> 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
> 
>