Subject: Re: [MOBILE-IP] R-P agent should listen on port 434?

From: Yingchun Xu <[email-masked]>
Date: Mon, 7 Feb 2000 14:18:17 -0600

Pat,
If you want to listen on the same "logical" interface, you are right that one
process is required to handle both types of registration.
Yes, a PDSN can have one ethernet interface but can be configured to be
different logical interfaces (multi-homing). In this case, the two registration
tasks
can be implemented into separated processes.

--Yingchun.

Patrice Calhoun <[email-masked]> on 02/07/2000 01:54:15 PM

Please respond to [email-masked]

Sent by:  Patrice Calhoun <[email-masked]>

To:   [email-masked]
cc:    (Yingchun Xu/MW/US/3Com)
Subject:  Re: [MOBILE-IP] R-P agent should listen on port 434?

Why *must* they listen on different interfaces? Is it not conceivable that
a PDSN (TR45.6 term for FA with lots of other functionality) can have
a single ethernet interface?

PatC
>
>I disagree.  They are on the same port but different interfaces.  This
>can be done with distinct processes.  UDP sockets are multiplexed
>based on both the port number and the IP address of the interface on
>which they arrive.  The "virtual" interfaces created by the R-P tunnel
>endpoints should be considered as logically distinct from the
>underlying device on which the tunnel is carried.
>
>-Pete
>
>Patrice Calhoun <[email-masked]> (PC) writes:
>
>PC> The fact that they both listen on the same port IMPLIES that the
>PC> current I-D requires that they be one process.
>

---

From: Patrice Calhoun <[email-masked]>
Date: Mon, 7 Feb 2000 12:35:18 -0800

Of course I have no particular problem with *adding* such a statement to the
current draft, since my base provides virtual interfaces. However, is this a
valid requirement that anyone implementing this feature *require* virtual
interface support?

PatC

---

From: Patrice Calhoun <[email-masked]>
Date: Mon, 7 Feb 2000 13:48:24 -0800

If it is agreed that it is valid for a host to support both MIP and
R-P as separate processes, then I would like to see some text in the
new R-P I-D that simply discusses these issues, since it isn't clear
to the reader (or at least me) that it was supported.

Simply requiring that the implementation be able to listen on specific
interfaces, and that the FA should attempt to send on a port other than
434, should do it.

PatC
>
>Ahh, you are talking about the registration requests/replies with the HA.
>
>Yes, if these come in on the same physical interface that supports the
>R-P tunnels, and if a user-space process is there to receive them,
>then port 434 there might be confusing.  If your FA doesn't support
>sending the requests on a different port (which is explicitly allowed
>by RFC2002), and you only have one physical interface, then you could
>run into trouble if your implementation tries to separate the two
>agents into separate processes.
>
>However, most of the time, a PDSN will have at least two physical
>interfaces and will behave much like a firewall.  That is, one
>interface will face inwards towards the RAN and one outwards towards
>the Internet.  Communication with HAs will always take place on the
>outward interface, and R-P tunnels will always be set up on the inward
>interface.  If you don't do things this way then elements of your RAN
>will be exposed to the Internet at large, which is not a good idea.
>Go look under your couch cushions for some change and buy a second
>ethernet card.
>
>-Pete
>
>
>PC> But the replies from the Home Agent would come back on port 434, unless the
>PC> FA forwarded the request from another port (and I am not sure that all
>PC> implementations support this). Therefore, it sounds like this is *still*
>PC> a problem.
>
>PC> No?
>
>

---

From: Roberts Phil-QA3445 <[email-masked]>
Date: Mon, 7 Feb 2000 18:56:12 -0600

Pat's suggestion is good.  My fear about this draft in general is that it
assumes a particular implementation for a particular architecture that is
connected "on the side" of the Internet.  For those who don't have the
background this could be quite confusing.  Pat knows a lot of the context
and has found this confusing, so it will likely be worse for others.

Phil

-----Original Message-----
From: Patrice Calhoun [mailto:[email-masked]]
Sent: Monday, February 07, 2000 3:48 PM
To: [email-masked]
Subject: Re: [MOBILE-IP] R-P agent should listen on port 434?

PatC

---

From: Ashish Mehta <[email-masked]>
Date: Tue, 8 Feb 2000 19:10:55 -0800

>
>
>I know there has been some discussion after this.
>
>
>
>> draft-ietf-mobileip-3gwireless-ext-02.txt alludes to R-P registration
>> messages being sent to UDP port 434. Does this imply that the mobile
>> IP agent (processing the MobileIP registrations) and the R-P agent
>> (processing the R-P registrations) are one and the same daemon/process?
>> It certianly appears so, since UDP would not be able to distinguish
>> between two unicast listeners on the same port.
>
>In this case it might be good to implment as one process.
>

The question I had in mind was  essentially:  as an  implementor  do I
have a  choice  of  implementing  the R-P and MIP  agent  as  seperate
processes.  So, it is not as much as what I can do  (which  your  mail
seems to address) but what am I allowed to do.Looking  at the spec and
the ensuing  discussion  I  understand  that it may not be possible to
seperate  them (and hence the  clarification  text  suggested by Pat).
Correct me if my understanding is incorrect.

ashish

>Implementation as one  process or multiple depends  of your system and
>design.  Although  the following  example  is a   little off,  hope it
>convays the meaning. One can implement  FA and HA functionality as one
>process or as two processes or even as  three processs as long as they
>communicate with each  other.  Similarly one  can  implement Mobile IP
>and RP message processing in one process or multiple.
>
>If you want  to  implelent as  two,   then you might  want some  third
>process to  do the  listening and communicate.   If  you can bind your
>socket an IP address as  well than you can  use different IP addresses
>and implement them.
>
>I am not saying  that this is a  best  way to do   this but just  some
>random thoughts.
>
>>
>> Would'nt this be a problem for vendors who want to productize only
>> a mobile IP solution and use  a third party  solution for the R-P
>> agent?
>
>I guess you will  run into the same  problem if one implements some of
>the   extensions and   want to use   other   extensions from an  other
>implementation.
>
>-Gopal
>
>