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

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

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

Yes, we need some examples.

--Tiru.

> -----Original Message-----
> From: Dave Thaler [mailto:[e-mail]]
> Sent: Tuesday, August 07, 2012 7:05 AM
> To: Tirumaleswar Reddy (tireddy); Reinaldo Penno (repenno);
> [e-mail]
> Subject: RE: [pcp] Comments on draft-ietf-pcp-dhcp-03
> 
> > -----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
> > >
> > >
> >
>