Subject: [Pppext] IPCP option for SIP server

From: Ashutosh Dutta <[email-masked]>
Date: Mon, 21 Nov 2005 21:58:06 -0500

I was trying to find the status of the draft
"draft-song-pppext-sip-support.txt", and came across the following
announcement, 

http://www.ietf.org/IESG/Announcements/rfcno-draft-song-pppext-sip-support.txt.

which says there  are already ways to take care of  this and thus this
never became  an informational RFC. I  could not find it  in the email
archive.  Can somebody please  point me  to the  right draft  where it
explains as to how to take care of assigning SIP server over PPP link?

It is very important to determine the IP address of the outbound SIP
proxy using PPP option.

Thanks
Ashutosh Dutta
Telcordia Applied Research

_______________________________________________
Pppext mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pppext

---

From: Karl Fox <[email-masked]>
Date: Mon, 21 Nov 2005 22:37:56 -0500

How about RFC 3361 (for IPv4; RFC 3319 for v6)?

Karl

---

From: Karl Fox <[email-masked]>
Date: Tue, 22 Nov 2005 00:31:27 -0500

It is relevant to a WAN environment.  DHCP runs over UDP, which runs  
over IP, which runs over PPP.  DHCP is a flexible, well-defined  
protocol that is easy to implement.  No protocol changes are needed.

Karl

On Nov 21, 2005, at 11:46 PM, Ashutosh Dutta wrote:
> Karl, thanks for your email.
>
> RFC 3361, and RFC 3319 talk about DHCP option for V4/V6
> respectively. I was more curious about PPP that is more relevant for
> Wan environment.
>
> Thanks
> Ashutosh
>
>
> Ashutosh

---

From: Ashutosh Dutta <[email-masked]>
Date: Mon, 21 Nov 2005 23:46:44 -0500

Thanks
Ashutosh

Ashutosh

---

From: Ashutosh Dutta <[email-masked]>
Date: Tue, 22 Nov 2005 07:32:52 -0500

Karl, in a 3GPP2 environment where the client gets an IP address from
PDSN over PPP link, my PDSN acts like a NAS which is also a PPP
server, and I may not have a DHCP server in that case.

I have used DHCP in LAN environment with SIP option.

Thanks
Ashutosh

Ashutosh

---

From: James Carlson <[email-masked]>
Date: Tue, 22 Nov 2005 08:15:17 -0500

> server, and I may not have a DHCP server in that case.

A "DHCP server" is no more difficult than an IP node that can send and
receive UDP packets.  If you don't have that, then it seems unlikely
to me that you've got a functioning IP network at all.

Note that you don't need stateful behavior to solve the problem.  A
simple DHCPINFORM will do the trick.

> I have used DHCP in LAN environment with SIP option.

And that's a good reason why it should *not* be added to PPP.  It's
redundant work.

A much better reason to avoid adding it to PPP is that it won't work
right.  Consider the following network:

   N1 <---PPP---> N2 <---Ethernet/other---> SIP server

In this case, you'd want N1 to learn about the IP address of the SIP
server that exists behind N2.  But the PPP (and IPCP) negotiation on
the PPP link terminates with N2.  This means that N2 needs to somehow
"know" that the SIP server exists and what its address is.

This implies that either N2 behaves as a proxy between this new IPCP
configuration option and DHCP, or that N2 has fragile statically
configured data for that address.

Either way, you're committing all of us (collectively) to producing
new ad-hoc extensions to IPCP that are proxied one-by-one into DHCP or
some local configuration that must be managed.  That solution is far
more complex and much less extensible than just having N2 behave as a
generic DHCP/BOOTP relay on behalf of N1, and allowing those protocols
to do what they're already designed to do.

The same problem afflicts the ill-considered DNS name server address
option, and I don't think we need to replicate that mistake.  Once, I
think, was plenty.

-- 
James Carlson, KISS Network                    <[email-masked]>
Sun Microsystems / 1 Network Drive         71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677

---

From: Ashutosh Dutta <[email-masked]>
Date: Tue, 22 Nov 2005 09:17:26 -0500

James, appreciate your thoughtful reply. As you have mentioned there
is certainly better way around to take care of this scenario if one
has a DHCP server sitting in the network where the NAS server is
connected.

I was refering to the case where the PPP server is configured to give
away the addresses and may not have any DHCP server configured in the
network to rely upon, in that case only way to provide SIP server, DNS
server etc. to the mobile obtaining the IP address may need a
mechanism where these parameters get stored locally in a NAS server
and are given out as part of IP address dispensing.

Regards
Ashutosh

Ashutosh

---

From: James Carlson <[email-masked]>
Date: Tue, 22 Nov 2005 11:40:04 -0500

> has a DHCP server sitting in the network where the NAS server is

Where "DHCP server" is no more complex an answer than "new IPCP
option."  In fact, the former is *less* complex because it involves
existing standards, while the latter requires forcing manufacturers to
add the option of interest and then deploying brand new software
(and/or hardware) to solve the problem.

Using existing mechanisms is generally a better idea, if you have a
choice.

> > "know" that the SIP server exists and what its address is.

You still have to have information on the SIP server's side of that
PPP link that somehow tells the PPP termination equipment the IP
address of the proper SIP server.

There are multiple ways to do this, but they're all much less robust
and less desirable than just using a simple DHCP exchange.

> > to do what they're already designed to do.

I don't see any good way out of that problem.  There are few ways for
N2 to have any *reliable* knowledge of the SIP server's address, and
the ways that do exist imply duplicative effort within IPCP to rebuild
all of the options currently available in DHCP.

I see no point to doing that, when sending and receiving UDP datagrams
is trivial.

---

From: James Carlson <[email-masked]>
Date: Tue, 22 Nov 2005 11:45:18 -0500

> and are given out as part of IP address dispensing.

Note that DHCP itself needn't necessarily be involved in the IP
address allocation strategy at all.  It's possible to use DHCP to
distribute configuration details without doing stateful address
allocation.  See the DHCPINFORM messages (cited earlier) for details.

---

From: Ashutosh Dutta <[email-masked]>
Date: Tue, 22 Nov 2005 12:11:20 -0500

> allocation.  See the DHCPINFORM messages (cited earlier) for details.

James agreed, PPP server itself can keep the IP address pool and
dispense it and DHCPINFORM can probably get other server details using
DHCPINFORM. Only requirement is then to have a DHCP server in the
backend and have a DHCPclient of some sort in the NAS server.

Thanks
Ashutosh

---

From: James Carlson <[email-masked]>
Date: Tue, 22 Nov 2005 12:38:17 -0500

> backend and have a DHCPclient of some sort in the NAS server.

If you instead put that client in the remote node ("N1" in my diagram)
rather than in the NAS ("N2" in my diagram, though I was intentionally
showing PPP itself as a symmetric link), then you don't need any PPP
changes at all, and you can get *ALL* of the other configuration
features of DHCP for free without needing to change IPCP for each one.

That's the point.  There's an existing solution that works well, is
widely deployed, and is quite easy to implement.  We thus don't need
another.

In addition to that, adding SIP configuration here would just beg
other questions.  Should Ethernet have a way to do this as well,
perhaps via 802.1X extensions?  Why shouldn't all L2 protocols do
this?  What happens if the remote node supports both DHCP and the
proposed IPCP option, and queries to these return different answers?
Which one is considered authoritative and why?

Adding new features to an existing protocol isn't a matter of "could,"
but rather a matter of "must."  In other words, we do it as a last
resort because nothing else can reasonably be made to work.  That's
not the case here.

---

From: Ashutosh Dutta <[email-masked]>
Date: Wed, 23 Nov 2005 08:27:34 -0500

> features of DHCP for free without needing to change IPCP for each one.

James, I can think of some optimization issue such as follows:

By running DHCPclient on the mobile while the mobile is using CDMA2000
RAN, one  uses PPP to  obtain an IP  address and DHCPclient  to obtain
other server parameters  and one needs to run both  the daemons on the
client to get fully configured. PPP has to happen and then DHCP. For a
rapidly moving client this may add to some optimization issue.

Thus if  the client is moving  between PDSNs this may  be bit overkill
but  may work  out  well if  the  same client  moves between  CDMA2000
network and WiFi for example.

Thanks
Ashutosh

---

From: James Carlson <[email-masked]>
Date: Wed, 23 Nov 2005 09:07:05 -0500

Ashutosh Dutta writes:
> client to get fully configured.

What "daemons?"  That's an implementation issue.

As for DHCP, we're talking about a single UDP packet exchange -- send,
receive.  That's it; it's stateless.  One round trip time, and no
"daemons" required.

> PPP has to happen and then DHCP. For a

I think that's nonsense because it ignores the larger picture.

When you switch SIP servers, you lose whatever state you had with the
previous server.  You likely need to redo computationally complex
operations such as public key crypto to secure the new connection.
That's probably the least of the worries.

However, this is IP.  IP doesn't care when links go up and down.
There's no reason you can't switch PPP links and keep the *same* SIP
server address over the transition.  Then, if you feel compelled to do
so, issue a DHCPINFORM message when you have the time, and if the
reply specifies a new SIP server address, switch.

You can do make-before-break and avoid any loss of service.

In addition to this, we're talking about a single round trip time.
Unless that cell phone is just doing nothing at all, any activity it
might do over IP dwarfs that one packet exchange.

Finally, if you're using a SIP server, the information you get back
includes things such as host names and addresses of other systems to
contact.  Again, the actual exchanges involved in even the lightest
transaction there dwarf the time it takes to discover the SIP server
address from a relatively local DHCP server.

So, I don't buy it.  I don't see how this is a worthwhile optimization
in any case, and it seems quite obvious that it's not generally useful
(nodes one or more hops away from the PPP link have no way to know
what was negotiated) and hard to deploy.

> network and WiFi for example.

The same issues exist there.  And, in fact, the implementation with
DHCP alone is *much* simpler, because you don't have to deal with
determining whether this new IPCP option (for the CDMA2000 link) or
DHCP (on WiFi) is authoritative.  Just rely on the DHCP answer in any
case.

---

From: Karl Fox <[email-masked]>
Date: Wed, 23 Nov 2005 09:44:03 -0500

And of course, we should all remember that the only issue of official  
concern to this audience is, "Is a protocol change necessary?"  The  
answer has already been established: No.  DHCP is the perfect  
solution for this problem.

Karl

---

From: Vernon Schryver <[email-masked]>
Date: Wed, 23 Nov 2005 09:01:40 -0700 (MST)

> From: Karl Fox <[email-masked]>

> solution for this problem.

Exactly.

We heard the "optimization" arguments many times over the years.  They
are utterly wrong, and always come from either people who have no
implementation experience or from people in big, disfunctional
organzations who feel that they can add code to their employer's PPP
implementation but not its DHCP implementation.

The other person in this case is probably in the first group, since
otherwise there would be no claims that DHCP would not already be in
use for getting the other parameters that are already in DHCP but not
in IPCP.  For example, isn't cellphone likely to want to do email?

Someone recently asked me privately about adding timezone name and
offset or Olson database pointer to IPCP.  That he accepted the
pointer to DHCP was a pleasant change of pace, but then he has been
around for a while.

Vernon Schryver    [email-masked]

---

From: Ashutosh Dutta <[email-masked]>
Date: Wed, 23 Nov 2005 11:07:38 -0500

James,

       Your points are well taken and I have really enjoyed having a
       good technical discussion on this topic here. I realize DHCP
       can do the trick over PPP link to get the server address
       configuration parameters.

       Just to reiterate, there are cases where each PDSN may have a
       different outbound proxy associated with it. Thus as the mobile
       mobile moves between PDSNs within the same DNS domain or AAA
       domain , it may end up getting a new outbound proxy or P-CSCF
       (in IMS language) during each transition. The point I was
       trying to make was that timing associated with outbound proxy
       configuration should not be neglected and should be considered
       during any handover optimization. Of course there are many ways
       it can be done, such as make-before-break as you have
       indicated. I was hoping if it can as well be done during the
       PPP negotiation phase itself, but DHCP appears to be cleaner
       solution at the moment, albeit an extra pair of message
       exchange. 

Regards
Ashutosh

Ashutosh

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 23 Nov 2005 08:24:32 -0800 (PST)

> rapidly moving client this may add to some optimization issue.

Actually, the opposite is true.  Doing IP configuration down in the link 
layer rather than in a single uniform way in the Internet layer would 
require hosts to implement a different configuration mechanism for each 
link type.  As hosts become increasingly multi-homed, this could lead to 
interoperability problems, code bloat, and slow handoffs. 

Since this question keeps coming up again and again, perhaps we need a 
document describing the basic principles.  A somewhat sketchy beginning is 
available here:
http://www.drizzle.com/~aboba/IAB/draft-iab-config-secure-00.txt

---

From: James Carlson <[email-masked]>
Date: Wed, 23 Nov 2005 11:33:42 -0500

Ashutosh Dutta writes:
>        (in IMS language) during each transition.

I agree that overconstrained problems are difficult to solve.

That doesn't mean that adding options to PPP is really the right
answer.

> The point I was

I agree that performance is important, but I wouldn't suggest a micro-
optimization such as this (moving an option from one protocol to
another) unless we've got hard data showing that this is an important
consideration (compared to all the other issues; there's no need to
optimize away 1% of the problem) and that there aren't more global
optimizations possible.

Such as, for instance, fixing the deployment so that these SIP servers
are accessible from adjacent cells.