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

[Dave Thaler <[e-mail]>]

> -----Original Message-----
> From: Tirumaleswar Reddy (tireddy) [mailto:[e-mail]]
> Sent: Sunday, August 5, 2012 2:46 PM
> To: Dave Thaler; Reinaldo Penno (repenno); [e-mail]
> 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.

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

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

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